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

[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

[Vidar Berg]

Hi Jens, I was referring to the nrjprog error "Cannot connect to any nRF device". A "deadlock" should not prevent the debugger from connecting. However, I think it makes sense to ignore that for now as it works on the other board you had. 

Jenzo said:

iMac:nrfjprog jenzo$ ./nrfjprog --reset

Applying system reset.

Run.

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

0x40000400: 00000004     

Did you turn the power off and on before you read the RESETREAS register here? In that case, the application is doing a soft reset. 

[Jenzo]

Hi Vidar,

Now I am performing a power cycle before reading the register! The bootloader used is the one you provided. 

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.

POWER CYCLE the device!

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

0x40000400: 00000004                              |....|

iMac:nrfjprog jenzo$

Regards

Jens

[Jenzo]

Sorry, but the second time I power cycled the device it read this:

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

0x40000400: 00000000                              |....|

iMac:nrfjprog jenzo$

[Jenzo]

Hi Vidar,

Considering that my battery powered device with output pins that control a DC motor, what could be wrong with my hardware? meaning how can the bootloader reset my board / reconfigure the PO.21?

The board is working fine without the bootloader.

Regards
Jens

[Nguyen Hoan Hoang]

Is your bootloader compiled with the same system_nrf52.c as your firmware ? It looks like that the bootloader is compiled with pin reset enabled.