My application board do not run example project

[Di-sheng]

Dear

           I have finished completed the Blue tooth Mesh light-switch example function testing , secure button dfu and secure buttonless dfu on DK and dongle of nrf52840 chips.

            Right now I build a testing circuit by nrf52840 module which was bought from vendor (The vendor said the modules are  bran-new which mean there is nothing in the nrf52840 chips). The circuit is built according to No5 circuit configuration schematic of nrf54280 datasheet(on page 593). A 3v3 exteral power connect to VDD and VDDH; Vbus be connect to USB power separately, which should be 5V. A SWD interface be connect to P19 of Dk(pca10056).

Below is some experiments I did and the result:

 

E1: Example:  open_bootloader of nRF5_SDK_16.0.0_98a08e2 : which locat at "nRF5_SDK_16.0.0_98a08e2\examples\dfu\open_bootloader\pca10056_usb_debug"

The " open_bootloader_usb_mbr_pca10056_debug.emProject" project be programmed to the module by SES through P19 of pca10056.

Every thing is ok. Becouse the LED blink to show it have enter the DFU state

Then I programmed the s140.hex and light_switch_server_nrf52840_xxAA_s140_7.0.1.hex to the module by USB with a 3v3 exteral power(The PCA10056 board be disconnected). the process looks good. But the code do not run, the led still blink after I push the reset button. there also is not any advertisements and LED also stay off.

E2: Example: secure_bootloader of nRF5_SDK_16.0.0_98a08e2 : which locat at "nRF5_SDK_16.0.0_98a08e2\examples\dfu\secure_bootloader\pca10056_usb_debug" and " nRF5_SDK_16.0.0_98a08e2\examples\dfu\secure_bootloader\pca10056_s140_ble_debug"

In this experiment, I will try 2 example project for USB dfu and ble dfu

After the module be erased by "nrfjprog -e" command through SWD interface which connect to P19 of pca10056, I programmed those 2 projects severally by SES and SWD interface.

After programmed "secure_bootloader_usb_mbr_pca10056_debug.emProject ", the desktop programmer tools can connect the module and also can write " the s140.hex and light_switch_server_nrf52840_xxAA_s140_7.0.1.hex". but the example code still do not run. it is same with E1.

After programmed " secure_bootloader_ble_s140_pca10056_debug.emProject ", the led is correct like as PCA10056 board, but there is not any advertisements.

 

The RF parts of the module does not work all the time. the light-switch server code can not be started by bootloader althrough it can be started on PCA10056 board.

 

Q1: Is there anything special we need to do to make a new NRF52840 chip work properly? (For example, the hard disk needs to be formatted before use)

Q2: Those testing result show me that the light-switch server code make the all of the pin stop output? why?

Q3: Is there any key to lock the flash so that the application code can not be write to flash?

 

Thanks,

 

Di-sheng

[Mttrinh]

Hi,

Can you check if your module have a 32khz crystal? It might be the reason for the issues you are seeing if you are missing this. 

Is there any key to lock the flash so that the application code can not be write to flash?

Do you mean like preventing reprogramming?

[Di-sheng]

Hi Mttrinh

Thanks for your replay.

Yes, I have realized that the lack of 32.768kHz crystal  may be the root of the problem. I can get parts today .

You are right. Is there any mechanism to prevent chip  reads and writes, how to do it and how to unlock it ?

Thanks!

B,Rs

Di-sheng

[Di-sheng]

Hi Mttrinh

I add the 32kHz crystal and the dfu code running correct now. I will try to run the light-switch server code tomorrow. 

I have other question about the code of the light-switch server example:

I read the  code of simple_hal.c, showed below:

 /*****************************************************************************
* IRQ handler(s)
*****************************************************************************/

#if BUTTON_BOARD
void GPIOTE_IRQHandler(void)
{
NRF_GPIOTE->EVENTS_PORT = 0;
for (uint8_t i = 0; i < BUTTONS_NUMBER; ++i)
{
/* Check that the event was generated by a button press, and reject if it's too soon (debounce).
* NOTE: There is a bug with this at the wrap-around for the RTC1 where the button could be
* pressed before HAL_BUTTON_PRESS_FREQUENCY has passed a single time. It doesn't matter practically.
*/

////////////2020-0828 button debug start
#if defined(BOARD_PCA10059) && !defined(BOARD_LSM100)
if ((~NRF_GPIO1->IN & (1 << (m_buttons_list[i]))) &&
TIMER_DIFF(m_last_button_press, NRF_RTC1->COUNTER) > HAL_BUTTON_PRESS_FREQUENCY)
#else
if ((~NRF_GPIO->IN & (1 << (m_buttons_list[i]))) &&
TIMER_DIFF(m_last_button_press, NRF_RTC1->COUNTER) > HAL_BUTTON_PRESS_FREQUENCY)
#endif ////////////2020-0828 button debug end
{
m_last_button_press = NRF_RTC1->COUNTER;
m_button_handler_cb(i);
}
}
}
#endif

I did not find the "m_button_handler_cb(i)" code in whole sulotion and nordic webs. Would you can help me to find it. I want to know what  does it.

Thanks,

B,Rs,

Di-sheng

[Mttrinh]

Di-sheng said:

Is there any mechanism to prevent chip  reads and writes, how to do it and how to unlock it ?

Have a look at Edvin's answer in this thread.

Di-sheng said:

I did not find the "m_button_handler_cb(i)" code in whole sulotion and nordic webs. Would you can help me to find it. I want to know what  does it.

m_button_handler_cb is the callback function for the buttons. 

Looking in hal_buttons_init(hal_button_handler_cb_t cb), you can see that m_button_handler_cb is set to cb. In main.c, hal_buttons_init is called with button_event_handler as argument which means that m_button_handler_cb is equal to the button_event_handler. You can find button_event_handler(...) in main.c

[Di-sheng]

Hi Mttrinh

Oh!  Yes. I miss that. 

Thanks,

B,Rs

Di_sheng