to clarify my question: I want to disable all the watchdogs/supervisors/timeouts/triggers started from the bootloader in a non permanent way (without deleting or touching and changing the bootloader).
I just this specific chunk of code, to hand over 100% control to the OS.
I want to find a solution for the spark community and the RIOT community, which will work for both.
So replacing the bootloader will require spark community hardware owners to have a jtag to reflash back to spark software…and I think this is not that nice. Same for RIOT users. So the bootloader with the dfu utility is a nice thing I want to preserve if possible.
Right now the led is just directly red and flashing every 4-5 sec, probably this chunk of code (from bootloader):
// Set IWDG Timeout to 5 secs
IWDG_Reset_Enable(5 * TIMING_IWDG_RELOAD);
perhaps we find a solution where I can set some bits to indicate my needs to the bootloader and then issue a reset. The bootloader should read that need and signal back (by setting some bits) that it accepted the request.
PS I updated by code in the RIOT repo, so you have a look at it:)
I managed to get it work:) I had to reengineer the bootloader, but it seems to work:)
code in the repo is updated, basically to signal the bootloader a successful update:
BKP->DR1 = 0xFFFF; // On successful firmware transition, BKP_DR1_Value is reset to default 0xFFFF
BKP->DR9 = 0xA << 12; // Do not enable IWDG if Stop Mode Flag is set
BKP->DR10 = 0x5000; // 0x5000 is written to the backup register after transferring the FW from
// the external flash to the STM32's internal memory
I am guessing the above mechanism is working as you have received the latest cores with the latest bootloader or did you patched the bootloader after you got the core? patching would be necessary, else the IWDG enabled in bootloader will always reset the core when put in low power mode(necessary for older cores).
Here is the Bootloader-patch firmware which will easily enable anyone in field to update to the latest bootloader without using JTAG programmer. Here is the core-firmware branch for this:
However care should be taken not to disturb the patch update process by accidentally removing usb power or through reset.
Following is the procedure to update the bootloader-patch
1)cd core-firmware
2)git pull
3)git checkout bootloader-patch-update
4)cd build [No need to run make]
5)Enter usb dfu/bootloader mode => Yellow flashes
6) dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin
7)Upon execution, the bootloader should be updated within a second or two and normal core-firmware should start executing.
8)Congrats! your core is loaded with latest bootloader without the hassle of going through ST-Link JTAG programming
Now simply writing BKP->DR9 with 0xAFFF in your custom firmware should cause the bootloader to skip the enabling of IWDG after reset.
thanks for your short how to update the bootloader! With the original bootloader my core was resetting every 3-5 sec.
With the new one there is no reset anymore, GREAT!
LED and UART are running so far, a problem on thread scheduling is still there. svc interrupt is not firing.
I’ll keep you updated! perhaps you guys at spark are interested in link to RIOT-OS when we got the core running. We will link from our supported platforms page to you.
I’m also open to discuss a possible cooperation!
Christian
PS: I’ll update by RIOT branch in the next minutes
I think the only missing part to call this board initially ported is the threading, for which I need working interrupts (with the jump targets in RIOT).
to make this second “operating system” interrupt table work I miss a piece of understanding how this might work at all…
the embedded LED and the UART are working so far via RIOT! (someone else is working on the CC3000 driver for RIOT)
Hi @christian, Either I didn’t understand your question correctly or you are mistaken/confused.
Both the bootloader and core-firmware interrupt vector table are located in Flash at different vector table base offset.
In bootloader code, the offset is set default to "0x0000"
In core-firmware, the offset is set to “0x5000” via the following call at the start of the program in SparkCoreConfig() called in the startup assembly code.
NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x5000);
Both the bootloader and core-firmware has its own interrupt handler code implemented/defined in stm32_it file found in the respective repos. The handler declaration is weak in the startup code.
If you are using a different startup file as in RIOT-OS, then be sure to rename/update the interrupt handler definitions in stm32_it appropriately else the code won’t link properly.
@christian, there’s absolutely no reason why you can’t use the spark bootloader to load any subsequent app/OS. I’m glad to see that you’re up and running. I think @satishgn has given you the hint you need to switch over to your own vector table.
Please keep updating us here, this is exciting stuff.
If you can publish notes on your journey that would be an enormous help - the spark firmware & bootloader were developed in tandem, and so there are going to be hidden assumptions that as an outsider you are in a unique position to uncover and document.
@satishgn NVIC_SetVectorTable was the missing hint for me…now the RIOT interrupt table is used and the threading is working! thanks a lot.
No one I asked so far was aware of this functionality, probably because we usually replace all the code on the chip, so it seems the spark core is the first RIOT device with a software bootloader:)
@AndyW I’ll update the RIOT wiki to reflect all my findings so far! perhaps you can fill it with nice information and links to represent your hardware. You can send updates for the wiki to my private mail address (have a look at github) or as pull request. Currently it’s not finished in any way (incomplete and unchecked information).
@all RIOT status so far: RGB working, UART working, threading working…“user led” not working so far, I’ll look in this later. After updating the RIOT wiki (@AndyW just send me stuff:) to integrate. I’ll make a pull request to bring spark support in RIOT master.
When you add threading, will shared resources be protected with a mutex to prevent concurrent access? E.g. two threads accessing external flash - one reading while the other writes. Does the system take care of that or is user code expected to deal with the multi-threading and serialize access to shared state?
I want to run RIOT-OS on a particle photon, the successor to the spark core.
I already found out that not the exact same cpu is used, so I guess one needs to create a new board definition for the particle photon? https://docs.particle.io/datasheets/photon-datasheet/#memory-map