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.

[Cyril]

Hello

did you take a look at the declaration of CONFIG_GPIO_AS_PINRESET in both your app and your bootloader?

Check the comment in system_nrf52.c:

/* Configure GPIO pads as pPin Reset pin if Pin Reset capabilities desired. If CONFIG_GPIO_AS_PINRESET is not
  defined, pin reset will not be available. One GPIO (see Product Specification to see which one) will then be
  reserved for PinReset and not available as normal GPIO. */

Best,

[Jenzo]

Hi Cyril,

I have defined the PIN reset to a normal GPIO. 

The app works fine. But the bootloader does not work. Strange, because both are using the same board file. 

regards

Jens

[Vidar Berg]

Hi Jens, 

Please readout  UICR.PSELRESET[x] after programming the bootloader to verify that it's not set. It should be 0xFF.. if pinreset is disabled. E.g., with nrfjprog

nrfjprog --memrd 0x10001200

This option is enabled if you build the project with CONFIG_GPIO_AS_PINRESET independent of what board file you use. 

Regards,

Vidar

[Jenzo]

Hi Vidar, 

Pinreset is disabled. Readout of memory: 0xFF. 

I am using mergehex to merge and nrfjprog to program the board. Does GCC compile it wrong?

Please help.

Jens

[Vidar Berg]

Hi Jens,

Thanks for verifying that the pinreset functionality is indeed disabled.  

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.

I don't recall seeing this issue. We did, however, have a bug where the buttonless app and bootloader placed data in the same flash region which would cause merge conflicts when combining the two. I think we fixed that in SDK 12.3.0.

The format of the settings page generated is the same regardless of the toolchain you use. Also, the bootloader would not have booted the app if you had an invalid settings page.  

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.

Are you able to debug the app to see what causes the reset? You can build with -DDEBUG to catch code assertions (error handler will perform a reset otherwise).

Best regards,

Vidar

[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

[Vidar Berg]

Hi Jens,

This sounds more like HW issue. Do you have any Output pins that control regulator supply, etc.? Please try attached bootloader (.hex) and see if you get the same result. It's based on the original project but without any re-configuration of the GPIO pins. 

nrf52832_xxaa_s132.hex

[Jenzo]

Hi Vidar,

I get the same result with the bootloader provided by you.

I do have output pins that control DC motor driver.

If it is a hardware problem, how can you explain the issue? It works perfectly without the bootloader.

Regards

Jens