boards/im880b: refactor code

[maribu]

Contribution description

Using the common STM32 board makefile provides all supported programmers for STM32 boards. This allows e.g. to flash with stm32flash via make BOARD=im880b PROGRAMMER=stm32flash flash.

Testing procedure

make flash and make term should still work for OpenOCD with ST-Links as before, but additional programmers should now be available. I was able to program with stm32flash.

Issues/PRs references

None

[maribu]

@jmfriedt: This may simplify your work flow. Care to give this a spin?

I got my two iM880B boards, btw. How exactly did you flash the boards to produce the clock error? Specifically, how are you triggering the reset and how to you control the BOOT input?

[jmfriedt]

At the moment I am manually programming the STM32 either using stm32flash or openocd/gdb-multiarch as documented at https://github.com/jmfriedt/RIOT_tests/blob/main/README.md
The reset signal is handled by OpenOCD/gdb when running continue (gdb command) from RAM, while I hit a push-button connecting RESET# to ground when flashing with RS232/stm32flash.
Please notice that @trabucayre has been trying to re-write from scratch the clock initialization sequence based on the libopencm3 library but had not, as of Aug. 1st, been able to isolate the faulty issue, other than identifying that randomly including delays (empty for loops) during the initialization sequence would make it fail, hinting at some PLL or oscillator status. Still looking into the issue ... at the moment I have two boards I can flash with stm32flash and reset to get them started which allows completing the project, but is far from satisfactory in terms of stability.
Thanks, JM

[maribu]

Thanks for your reply. I am sadly still not entirely should about the exact steps to produce the issue.

Is it something like that:

1. Pull BOOT high
2. Briefly pull RST low to trigger a reset
3. Run stm32flash
4. Pull BOOT low (e.g. by releasing it and letting the iM8080B pull-down resistor pull it low)
5. Wait for BOOT to actually be low (when the weak pull-down resistor does this, it may take a brief moment)
6. Briefly pull RST low to trigger a reset

And with the last stable release, this would then boot RIOT just fine, while with current master it may not boot on some boards. Right?

[jmfriedt]

Correct, I have not been clear enough, here is the procedure I follow.
With stm32flash:

• pull BOOT/P16 high
• pull RST# low while BOOT/P16 is high
• release RST#
• release BOOT
• run stm32flash -w bin/im880b/binfile.bin /dev/serialportinterface
• hit reset briefly after programming is completed to launch the program

With openocd there is no manual handling of the board since the STLink/v2 signals are supposed to take care of all the actions:

• launch openocd
• launch gdb-multiarch bin/im880b/binfile.elf
• in gdb: target remote localhost:3333
• in gdb: monitor reset halt
• in gdb: load
• in gdb: continue

with the last 3 commands repeated as many times as needed to get the message displayed on the serial port terminal monitoring communication at the same time.
Thanks.

[maribu]

OK, I see. I was using stm32flash to control the RST and BOOT pin via the RST and DTR pin of the TTL adapter and issuing another reset after the flash sequence was completed. I think this prevented me from reproducing the issue.

Did you add an -g 0x0 to the stm32flash command to trigger execution from flash? The man page of stm32flash says:

EXAMPLES

Get device information:

    stm32flash /dev/ttyS0

Write with verify and then start execution:

    stm32flash -w filename -v -g 0x0 /dev/ttyS0

Read flash to file:

    stm32flash -r filename /dev/ttyS0

Start execution:

    stm32flash -g 0x0 /dev/ttyS0

Specify:

• entry sequence: RTS=low, DTR=low, DTR=high
• exit sequence: RTS=high, DTR=low, DTR=high

    stm32flash -i -rts,-dtr,dtr:rts,-dtr,dtr /dev/ttyS0

I read this as one has to either trigger a reset via an exit sequence (as I did), or has to issue -g 0x0 to actually get the board running from flash.

[jmfriedt]

I edited my comment to add that after programming using the RS232 port, the program is supposed to be executed by resetting manually the microcontroller.
@trabucayre didn't like manipulating wires every time we programmed the microcontroller and wired as you did two FT232 GPIO to handle the RST# and BOOT pins, with the same difficulties in getting the software to start.

[maribu]

@jmfriedt: Just one last question: The boot issue only appears after being flashed with stm32flash, correct?

Two causes for such behavior come to my mind:

1. The content of the flash is different after being programed with OpenOCD or stm32flash. In this case when programed with stm32flash the issue should remain persistent, even when cold booting the MCU (e.g. plugging out the power source and plugging it back int)
2. The issue is because the in-ROM bootloader brings the MCU into a step from which RIOT cannot boot reliably. I think that just entering the bootloader and starting execution from flash from there (e.g. stm32flash -g 0x0) should in this case also trigger the issue, even if the flash was previously written by OpenOCD.

I will check if I can reproduce the issue with the second iM880b board of mine. (But I have to solder some wires to it first.)

[jmfriedt]

@jmfriedt: Just one last question: The boot issue only appears after being flashed with stm32flash, correct?

no, both openocd/gdb-multiarch and stm32flash display random startup sequences depending on the board. Some board work flawlessly with stm32flash, allowing to complete my application, some boards start well with openocd "continue" but fail with stm32flash. With openocd after many (>5) retries of reset/load/continue I end up having a running program.

Indeed @trabucayre is also thinking the bootloader/program transfer is the cause of the problem rather than RIOT-OS, but then I fail to understand why the pre-Sept 2020 version of RIOT is working flawlessly on all boards.

Thanks for looking into this.

1. The content of the flash is different after being programed with OpenOCD or stm32flash. In this case when programed with stm32flash the issue should remain persistent, even when cold booting the MCU (e.g. plugging out the power source and plugging it back int)

2. The issue is because the in-ROM bootloader brings the MCU into a step from which RIOT cannot boot reliably. I think that just entering the bootloader and starting execution from flash from there (e.g. `stm32flash -g 0x0`) should in this case also trigger the issue, even if the flash was previously written by OpenOCD.

[aabadie]

ACK