Customizing a bootloader

[p143]

If all you need is changing  PHY, Tx power and Device Name in a standard nRF52840, do you need building a new bootloader from the scratch or the is a way to edit the standard firmware,  build a new edited file and finally re-program this file in a standard nRF52840? Thanks

[Vidar Berg]

Hi Juan,

I'm fine, thank you. I kept the default power settings when I created the sample code, but even if I did it should not have had any impact on POR. My guess is that you get a code assertion after boot that causes the program to hang inside the app_error_fault_handler() function. Are you able to debug the application to see if your program reaches main()? Do you have debug logging enabled?   

Regards,

Vidar

[p143]

No. I do not

[Vidar Berg]

Can you run "nrfjprog--readregs" after you've programmed the FW and post the result here?

[p143]

Hi Vidar.

Here you have the readregs command output snapshot: 

This is the snapshot when the module is programmed with your original ble-uart modified file, which presents exactly the same symptoms than the later modified files we built in our own, further modifying few more parameters. Thanks for your help. 

Juan

[Vidar Berg]

Hi Juan,

It looks like your program is entering the app_error_fault_handler() from the UART callback.

Try to comment out the "APP_ERROR_HANDLER(p_event->data.error_communication);" line for the APP_UART_COMMUNICATION_ERROR event and see if that helps. 

[p143]

Hi Vidar.

I took good care in using your modified file and not mine, so the problem should be easy to trace for you, since only you know the changes which were introduced.

If you can't reproduce in your lab this simple, critic and repetitive failure I described, and it only happens to me, this would necessarily mean that the culprit would necessarily be either the module+host PCB I am using myself (NINA-B306 in this case) either the Power supply. The power supply I am using, is a battery from a very recognized Lithium Polimer manufacturer, and the problem also happens if I use a professional power supply, so I would take this reason out of the failure candidates.

Regarding the module, remember that mine works perfectly when instead your file, I program the SDK v15.2.0 original ble-uart app, all this meaning that most probably, the problem comes from any of the code modifications made on your file.

All this said, I will be glad (always with your guidance) to try and discover which is the code line in your file causing the problem, but before, it would be encouraging to know if the problem I described, happens also to you or nor, since I am not fully familiarized with all your code functions, commands and argot etc. and is going to be a tough job. Thanks.

Waiting on your comments,

Best regards

Juan

[Vidar Berg]

Hi Juan,

There's nothing that indicates problems with the power supply. Your application code is running fine except that it seems to be ending up the error handler as I mentioned. I suspect it happens because of an UARTE error condition which is why I asked you to comment the "APP_ERROR_HANDLER(p_event->data.error_communication);" line. An error condition can for instance occur if you have a floating RX input. 

[p143]

I see. But were in within all program should I  write this  "APP_ERROR_HANDLER(p_event->data.error_communication);"  sentence?