MBR PARAMETER not installed when i flash SD+BOOT+APP

[Julien]

Hi,

For my project, firstly i erase all the user program, and then I install succesively the softdevice (s132 v6.1.0), the bootloader and my application software with nrfjprog.

This work well, but with one of my device, neither the bootloader or the application has started.

After investigation, i observe with nrf connect that the MBR parameter is not set with the device impacted.

                                                                                                            

                                         Device OK                                                                                                                                             Device not OK

So my question is why the MBR Parameter is not set automatically ? 

Thanks,

[Vidar Berg]

Hi,

The bootloader configures the MBR param and bootloader settings pages on the first boot. So the fact that both pages are empty indicates that the bootloader has not been run for some reason. Were you able to get this particular device to work if you reflash it? If not, try to run "nrfjprog --readregs" and see if it is stuck at a certain address (see PC register value). Also, please include the --verify argument when programming to make sure the image is loaded correctly.

eg.,

nrfjprog --program <>.hex --chiperase --verify -r 

[Julien]

Hi, 

The device doesn't work even if if i reflash it. The verify argument is always used when i program the device.

Si I run "nrfjprog --readregs" and i have the following result with the impacted device :

R0:   0x0000C277
R1:   0x00000000
R2:   0x0007A0B0
R3:   0x20009BD4
R4:   0x00000021
R5:   0x0007A0A1
R6:   0x0007A0A0
R7:   0x0000FA00
R8:   0x00000000
R9:   0x00000000
R10:  0x00000000
R11:  0x00000000
R12:  0x40000614
SP:   0x20009BE8
LR:   0x00075C15
PC:   0x0007A0A0
xPSR: 0x21000000
MSP:  0x20009BE8
PSP:  0x00000000

To compare i send the same commande with an other device, and we have this result :

R0:   0x01000001
R1:   0x40020518
R2:   0x00000001
R3:   0x00000000
R4:   0x200000C0
R5:   0x00000000
R6:   0xE000E000
R7:   0x0000006F
R8:   0xA5A5A5A5
R9:   0xA5A5A5A5
R10:  0xA5A5A5A5
R11:  0xA5A5A5A5
R12:  0xA5A5A5A5
SP:   0x2000B5C8
LR:   0x00015C7D
PC:   0x00015C7E
xPSR: 0x61000000
MSP:  0x2000DAF8
PSP:  0x2000B5C8

I don't find the documentation to understand clearly the different field.  

[Julien]

It's come from the SCL pin, she always high. I take off my I2C chip, and even after that impossible to put the pin to low. I checked for a short circuit but nothing.

Maybe this pin is just failing. 

[Vidar Berg]

Do you have external pull-ups? In that case, have you tried to drive the line low from the nRF? 

[Julien]

Yes, i tried but doesn't change anything.

[Vidar Berg]

What about the SDA line, does it also stay high like the SCL line?

[Julien]

No, for the SDA line it's OK, i see the signal expected

[Vidar Berg]

Ok, thanks for confirming. It sounds like the GPIO from the nRF is not properly connected then. 

[Julien]

All right, thank you for your help