jump_to_application doesn't clean up after dapboot

[obra]

One common feature of bootloaders is that they try to leave the MCU's state as they found it, turning off interrupts, resetting clock config, etc.

I've tracked some weirdness I'm seeing in user applications down to dapboot not doing any of that. Is this a conscious choice or just something that hasn't been dealt with yet? I'm not experienced enough with opencm3 to propose a patch :/

[devanlai]

It's not exactly a conscious choice, more of a "it was good enough at the time so I didn't change it".

Off the top of my head, the bootloader doesn't turn on too many things:

1. It does configure the main system clock and leave it running.
2. It turns on and leaves on the GPIO peripherals and RTC backup register peripherals
3. If it enters DFU mode, it turns on USB and leaves it on

If you want something a little more limited in scope than trying to fix everything everywhere, I think the easiest place to fix up just the things that your application is sensitive to would be in target_pre_main(), which gets called immediately before setting the stack pointer and jumping to the application's reset handler.

[obra]

Understood. The specific manifestation of the problem I have is admittedly pretty special to my use of dapboot. Gigadevice's standard library assumes that clocks are in a known state at initialization time. And when they're not, all sorts of fun stuff happens, and the way our Gigadevice Arduino core works, it's a pain in the ass to inject code to bulletproof things in the right place on the user code side. (At the moment, I'm unwinding the chip trying to talk "regular" 100KHz I2C ...at 8MHz, but I haven't chased it all the way down yet.)