Bootloader and settings problem - gcc compiler

[Jenzo]

I have a custom board with an application that works fine. 

But when adding a secure bootloader my board starts to act weird. I am using the RESET pin on the chip as an input PIN. My chip resets every time the input is used when the app is run with the bootloader. But it works fine without the bootloader.

I am running SDK13 - Softdevice 4.0.5 on a nrf52832CIAA. 

I am compiling with gcc - both the app and bootloader. I have used nrfutil to create bootloader settings file. 

I have used merge-hex to merge the SD, app, Bootloader and settings-file.

All has been run on a MAC / OSX.

I have read somewhere on the Nordic DEVZONE that the gcc compiler places the settingsfile in the wrong place of the memory map. But I lack a good method of fixing it.

[Jenzo]

Hi Vidar,

I know exactly why is resets! It resets when the input on PO.21 goes high. On my custom board I have a sensor that is active high.

When the bootloader is not programmed on the nRF52832 then it works fine. But as soon as the bootloader is programmed then it resets every time the sensor activates. 

What could I have done wrong?

Regards
Jens 

[Vidar Berg]

Hi Jens,

I get that it resets when you use P0.21, but we don't know why. Can you check the POWER->RESETREAS register on startup to see what the reset source is? 

Jenzo said:

What could I have done wrong?

I suspect it's caused by a peripheral (GPIO for instance) being initialized by the bootloader that's not being properly reset before booting the app. And that this somehow breaks the app. 

Best regards,

Vidar

[Jenzo]

Hi Vidar,

I just read the memory after startup with the bootloader and I get this result:

iMac:nrfjprog jenzo$ ./nrfjprog --memrd 0x40000400 --n 4

0x40000400: 00000004 

I am not sure if it is the right memory address that I am readiing?! If it is the right address then I am not sure what the result means but I am sure you know:)

regards

Jens

[Vidar Berg]

Hi Jens,

Yes, you're reading out the correct register. Bit 3 indicates that the reset source is SREQ (i.e., soft reset). But I forgot to add that you should power cycle the board before checking the register. This is to ensure you do not see the reset performed by the debugger. 

The app must have called NVIC System reset if the bit is still set after a power cycle.  

[Jenzo]

Hi Vidar,

First time I performed the procedure the board got into a deadlock, possibly because it resets constantly:

iMac:nrfjprog jenzo$ ./nrfjprog --eraseall

Erasing user available code and UICR flash areas.

Applying system reset.

iMac:nrfjprog jenzo$ ./nrfjprog --program bl_blset_app_sd_v22.hex

Parsing hex file.

Reading flash area to program to guarantee it is erased.

Checking that the area to write is not protected.

Programing device.

iMac:nrfjprog jenzo$ ./nrfjprog --reset

Applying system reset.

Run.

iMac:nrfjprog jenzo$ ./nrfjprog --memrd 0x40000400 --n 4

ERROR: Cannot connect to any nRF device. Please make sure a device is

ERROR: connected to the debugger and supplied.

iMac:nrfjprog jenzo$ ./nrfjprog --memrd 0x40000400 --n 4

ERROR: Cannot connect to any nRF device. Please make sure a device is

ERROR: connected to the debugger and supplied.

iMac:nrfjprog jenzo$

I used another board and got this result:

iMac:nrfjprog jenzo$ ./nrfjprog --eraseall

Erasing user available code and UICR flash areas.

Applying system reset.

iMac:nrfjprog jenzo$ ./nrfjprog --program bl_blset_app_sd_v22.hex

Parsing hex file.

Reading flash area to program to guarantee it is erased.

Checking that the area to write is not protected.

Programing device.

iMac:nrfjprog jenzo$ ./nrfjprog --reset

Applying system reset.

Run.

iMac:nrfjprog jenzo$ ./nrfjprog --memrd 0x40000400 --n 4

0x40000400: 00000004                              |....|

iMac:nrfjprog jenzo$

Regards

Jens