Discussion around the Swiss Micros DM42 calculator.
akaTB
Posts: 570
Joined: Tue May 02, 2017 1:56 pm
Location: Milan, Italy

mcc wrote:
Mon Jun 04, 2018 5:02 am
What is check_qspi_crc? I dont have such and it is unknown by the GENTOO-distro-repository.
Where can I get it?

Check last link by Michael, bin subfolder.
Greetings,
Massimo
ajcaton
-+×÷ left is right and right is wrong Casted in gold
emece67

Perhaps I'm missing something here but, how does one compile the DMCP?

Regards.
toml_12953
Posts: 700
Joined: Wed May 03, 2017 7:46 pm
Location: Malone, NY USA

I got both parts installed but what's the PGM part for?
Tom L

If I buy someone a drink to congratulate them, is it a Mazel Tov cocktail?

DM10L SN: 059/100
DM41X SN: 00023 (Beta)
DM41X SN: 00506 (Shipping)
DM42 SN: 00025 (Beta)
DM42 SN: 00221 (Shipping)
mcc
Posts: 236
Joined: Fri Jun 23, 2017 5:10 am

Hi akaTB,

Thanks a lot!
Maybe the makefile could use the PATH into that bin-folder
instead of searching system wide and fail?

Cheers!
Meino
DM 42 - SN: 00373, Firmware release v.:3.16. / DMCP 3.20. as compiled by SwissMicros
mcc
Posts: 236
Joined: Fri Jun 23, 2017 5:10 am

emece67 wrote:
Mon Jun 04, 2018 5:27 pm
Perhaps I'm missing something here but, how does one compile the DMCP?

Regards.

For Linux:
At first you need a target compiler/cross compiler for that, generating ARM-Code (CoreM3),
since the heart of our beloved DM42 is a STM32-cpu .

Type 'make' while following the steps described in the README and...VOILA!
There it is.

@Micheal: Is there a chance of checking that the compiled product is a valid firmware
before flashing it?

The command "file" on the two files in question gave here:
DM42PGM_flash.bin: Compiled PSI (v1) data
DM42PGM_qspi.bin: data
which looks a little "very strange" to me...

In comparison:
The same "file" command on the FORTH-firmware for my STM32F103C8T6 gave:
mecrisp-stellaris-stm32f103.bin: DOS executable (COM, 0x8C-variant)
which is different but also very strange...but I know, that this firmware works fine.

Cheers
Meino
Last edited by mcc on Mon Jun 04, 2018 7:05 pm, edited 1 time in total.
DM 42 - SN: 00373, Firmware release v.:3.16. / DMCP 3.20. as compiled by SwissMicros
mcc
Posts: 236
Joined: Fri Jun 23, 2017 5:10 am

Hi Michael,

from experimenting with the "Blue Pill"-board, which has a STM32F103C8T6 (which by no means is comparable
to the "power cookie" of the DM42...but at least it is an STM32 ARM processor, too), I know, that the STM32F103 is
nearly unbrickable as long as one dont plan exactly how to brick the chip. This is due to the bootloader being in the
ROM and therefore not alterable (as far as I know...).

How is the situation when it comes to the DM42?
When looking at the PCB then I see at least one UART and one SPI and some other contacts which looks like interfaces
like those.

When we will dive into the adventure of being a creative part of the "Great Family of DM42 owners"...how "risky" (not really
speaking of a risk here...its only my Denglisch/Genglish) will it be, to flash a modified firmware onto the DM42?
As with the STM32F103...is there a fall-back, a never shut door into summer, a """backdoor""" (only meant positively), to
recover from a bloody programming error one did while adding the "one plus ultra modification" to the firmware?

On my desk there is a soldering iron, an USB-to-serial adapter (3.3V/5V), two different STLINKv2-clones and if I flash the
according firmware to one of my STM32F10C8T6-boards I can add a "Black Magic Probe" to that.
No oscilloscope, though.

What is the safest way to test modifications of the firmware?
What ways out of lock-ups, endless loops and soft bricks are there?

Thanks a lot for any help in advance!
Cheers!
Meino
DM 42 - SN: 00373, Firmware release v.:3.16. / DMCP 3.20. as compiled by SwissMicros
Vitasam
Posts: 239
Joined: Thu Jun 01, 2017 11:51 am
Location: Finland
Contact:

mcc wrote:
Mon Jun 04, 2018 6:04 pm
Hi akaTB,

Thanks a lot!
Maybe the makefile could use the PATH into that bin-folder
instead of searching system wide and fail?

Cheers!
Meino
I also noticed the same error when trying to build the project:

Code: Select all

...
arm-none-eabi-objcopy --only-section   .qspi -O ihex    build/DM42PGM.elf  build/DM42PGM_qspi.hex
arm-none-eabi-objcopy --only-section   .qspi -O binary  build/DM42PGM.elf  build/DM42PGM_qspi.bin
check_qspi_crc DM42PGM dm/qspi_crc.h || ( make clean && false )
...
So the bottom line is: HEAD from GIT /master is broken now

Makefile should be updated. Could one make a pull-request?
Elektronika MK-61, Elektronika MK-52, HP15c LE, DM42 SN#16 FW 3.18
emece67

Studying the code I see that the source code for 100+ functions is not included. Instead such functions are called via hard-coded pointers pointing to addresses inside what seems to be a closed source library loaded at a fixed address in memory.

Can't see a way how this can be compatible with the statement: "[...] we will be releasing the full source code to be able to build your own DM42 firmware. All components of DM42 will be open-sourced" [bold is mine].

Regards.
Michael
Posts: 245
Joined: Wed Apr 05, 2017 11:31 pm

mcc wrote:
Mon Jun 04, 2018 6:33 pm
... I know, that the STM32F103 is nearly unbrickable as long as one dont plan exactly how to brick the chip. This is due to the bootloader being in the
ROM and therefore not alterable.

How is the situation when it comes to the DM42?
That's the same with the STM32L476. On the PCB there are two buttons, RESET and PGM. If PGM is pressed during pressing RESET, the bootloader kicks in the dm_tool can be used to flash it with a good firmware.
Vitasam wrote:
Mon Jun 04, 2018 8:20 pm
mcc wrote:
Mon Jun 04, 2018 6:04 pm
Maybe the makefile could use the PATH into that bin-folder
I also noticed the same error when trying to build the project:
...[/code]

So the bottom line is: HEAD from GIT /master is broken now
Nope, it's not broken, but RTFM my friend. In the readme it says:
Add GNU ARM toolchain and bin/ directory path to PATH.

The file check_qspi_crc is in the /bin/ directory and you need to put that directory in your PATH.
Michael