Ok, this one seriously has me stumped...
I have a custom bootloader that is modified from the DFU example (SoftDevcie S110 8.0, with SDK 9.0, using gcc). BLE is not used, it is pretty simple actually in that it just checks external SPI flash for a firmware update and if it is available, it copies it over.
The bootloader works fine. I have compiled it using the same make file as provided with the Nordic examples, modified to include all my own source files, and it works. No problem. Every time. We'll call this the "old" bootloader.
However, I modified the build process recently to the framework in which I work. So the make file is different, and I am adding a few things to the bootloader. Mainly, information about what it is is stored right behind the Vector table (and this isn't the culprit. I do the same thing with the system code and it works just fine.) I also add a CRC check onto the end of the bootloader. These changes are added to the linker scripts. I use this same build process with the application code and that works (with or without the "old" bootloader). So I don't think there is anything inherently wrong with the build process. We'll call this the "new" bootloader.
Now, here is the messed up part. This "new" bootloader works fine, until I reboot the device. Once I power cycle the device, nothing happens. The absolute very first thing I do in the bootloader's main function is to set a GPIO pin high, which is connected to an LED. When I flash with a JLink programmer and the system restarts, it works. If I don't power cycle the system, it seems to continue to work. But, when I power cycle the device, nothing happens. Once I power cycle, the bootloader doesn't seem to be getting called (neither is the application) and the system just does nothing.
One thing, I did take out setting the UICR register from my bootloder. I need bin files and if I leave that in the bootloader, the bin file is like 256M. However, I used the "old" bootloader to set the register, and I can verify through JLink that it is set properly even once the system hangs. So the UICR register is correct.
So, there is nothing wrong with the hardware since it works fine with the "old" bootloader. There is nothing wrong with the bootloader code since it works fine when I compile it the "old" way. This new way is somehow causing issues and I am not sure what it is.
According to my understanding of the MBR, it will look into the UICR bootloader and if it sees something it will try to hand over to that vector table. But that doesn't seem to be happening in my case? I am not sure what is going on.
Any thoughts/advice?
