S130 crashes on Fujitsu module with 16 KB of RAM

[ppatierno]

Hi all,

I'm working with the Nordic nRF51422 DK that has the nRF51422 chip with 32 KB of RAM. My application works great on it using the SoftDevice S130 as BLE stack.

Our final product is based on Fujitsu MBH7BLZ07 who has nRF51822 with 16 KB of RAM. I know that S130 uses 10 KB of RAM but my application fits in 6 KM of RAM.

We are facing with random crashes (Hard fault handler is called) on the Fujitsu module while application works fine on Nordic DK. To reduce our application load at minimum we commented all functions and leave only BLE related functions so that the main is the following :

ble_stack_init(); scheduler_init();

// Enter main loop ... ... ...

We saw that the application crashes in the Hard fault handler when it calls sd_ble_enable function inside ble_stack_init.

Any idea about the problem ?

Thanks, Paolo

s130 programming error.jpg

[Susheel Nuguru]

Please debug it into the ble_stack_init function and tell us what error code was returned inside it. There are few APP_ERROR_CHECK macro inside that function and if err_code is not NRF_SUCCESS it will reset your chip.

[ppatierno]

I already debug into ble_stack_init. When I call the sd_ble_enable it doesn't return but the code jumps to the hard fault handler

[Susheel Nuguru]

If the hardfault is triggered inside and seems like SOFTDEVICE_HANDKER_INIT was successful, then you can put a breakpoint at assert_nrf_callback function, which will be called when softdevice asserts. Atleast we can get the file and line number inside softdevice where hardfault was generated and I can look into it.

[ppatierno]

Just to give you more information ...

Enviroment and Hardware Windows 7 MDK 5.14 SoftDevice 8.0.0

Fujitsu MBH7BLZ07 with nRF51822 CEAAE00 cpuid (0x0079). rom 256KB ram 16KB cpu version 3

We decided to restart from a simple code and copying it from one of the example in nordik sdk. The initialization should be always the same for all the examples. The only difference is :

// Initialize the SoftDevice handler module. SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION, NULL);

because the fujitsu soc doesn't mount external low frequency crystal.

For that test we create a new custom board in "custom_board.h" with no led and button, to make the test more clean and simple as we can. The rom starts at 0x18000 and the size is 0x28000, tha ram starts at 0x20002000 and the size is 0x2000.

I updated the post with a screenshot of assert_nrf_callback.

[Susheel Nuguru]

your attached screen shot gave me some useful information. I can now see where inside the softdevice the fault is generated. Can you comment out sd_ble_enable and confirm me that hardfault is still triggered (it should, if the data in the screenshot has to make sense)

If the hardfault is still triggered after you comment out sd_ble_enable, then it seems that there is some hardware issue i need to investigate.