Hello,
I modified the ble_app_blinky example to work on our board (removed leds and buttons) and modified the board pca10040.h
the new application worked on the devkit but not in our board.
As the chip in the devkit is not the same used on our board (NRF52832-QFAB-R) is there any thing that I need to modify? like ble_app_blinky_gcc_nrf52.ld?
Thanks.
Hello,
You should probably adjust the memory settings to match the chip variant that you have. Check this table:
So if your device has 256kb/32kB Flash/RAM, you need to change the ble_app_blinky_gcc_nrf52.ld
Now it probably says something like:
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x5a000
RAM (rwx) : ORIGIN = 0x20002a98, LENGTH = 0xd568
This means that the application can use:
The flash from address 0x26000 to 0x80000 ( = 0x26000+0x5a000)
The RAM from address 0x2000 2a98 to 0x2001 0000.
The Flash is mapped from 0x00000000 to 0x0008 0000, and the RAM is mapped from 0x2000 0000 to 0x2001 0000. on the 512/64 kB devices.
The reason the origins are not on 0x0000 0000 and 0x2000 0000 is because some of it is reserved for the softdevice.
On the 256/32 kB version, the Flash is mapped from 0x0000 0000 to 0x0004 0000, and the RAM from 0x2000 0000 to 0x2000 8000.
So adjust the LENGTH so that ORIGIN + LENGTH equals 0x40000 in Flash and 0x2000 8000 in RAM.
Now, this is probably not the issue that you see in ble_app_blinky, because this application doesn't use particularly much flash or RAM.
What you probably will see is if you run e.g. the blinky example from SDK\examples\peripheral\blinky, it will work, but the examples from SDK\examples\ble_peripheral will not work. If that is the case, it is probably because your custom board doesn't have an external LFXTAL. Do you have that? If you don't have it, you need to set the softdevice to use the RC Oscillator instead of the external XTAL. I don't know what SDK you use, but in SDK15.3.0, look for NRF_SDH_CLOCK_LF_SRC, and set it to 0. There are some more defines you should adjust. You can start with these:
#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_ACCURACY 1
Try these configs, and see if you can see the advertisements. If not, have you tried debugging the application on the custom PCB?
Best regards,
Edvin
I want to add a new result:
As I said I used to program the custom device with https://www.silabs.com/documents/public/user-guides/efm32lg-stk3600-ug.pdf
We used to use that device to program the NRF51 in our old hardware version and to program the main MCU, and we never had such issue.
I tested today to program our custom board using NRF52 DK by making the connection described here: https://devzone.nordicsemi.com/f/nordic-q-a/14058/external-programming-using-nrf52-dk
Using the NRF52DK resolve the problem. have you any Idea of the difference between the two board? As the production lines are already equipped with the silabs devkit it will be easier to make just a firmware changes than adding new equipment !
Hello,
I am not familiar with the DK that you link to, what it uses, and how it works.
I see that you uploaded a picture from the callstack, where the reset handler was called. Can you show me the rest of the callstack as well? Maybe it can give some hints as to what went wrong.
BR,
Edvin
Below all calls:
//////////////////////////////////////1/////////////////////////////////////////
void bsp_board_init(uint32_t init_flags)
{
#if defined(BOARDS_WITH_USB_DFU_TRIGGER) && defined(BOARD_PCA10059)
(void) nrf_dfu_trigger_usb_init();
#endif
#if LEDS_NUMBER > 0
if (init_flags & BSP_INIT_LEDS)
0000 030C 07C2 LSL R2, R0, #31
0000 030E D407 BMI #+0x0E ;<nrf_gpio_cfg> ;320
{
bsp_board_leds_init();
}
//////////////////////////////////////2/////////////////////////////////////////
__STATIC_INLINE void nrf_gpio_cfg_output(uint32_t pin_number)
{
nrf_gpio_cfg(
0000 0320 F04F 43A0 MOV R3, #0x50000000
0000 0324 2103 MOVS R1, #3
pin_number,
NRF_GPIO_PIN_DIR_OUTPUT,
NRF_GPIO_PIN_INPUT_DISCONNECT,
NRF_GPIO_PIN_NOPULL,
NRF_GPIO_PIN_S0S1,
NRF_GPIO_PIN_NOSENSE);
}
///////////////////////////////////////3////////////////////////////////////////
__STATIC_INLINE void nrf_gpio_port_out_clear(NRF_GPIO_Type * p_reg, uint32_t clr_mask)
{
p_reg->OUTCLR = clr_mask;
0000 0326 F44F 3280 MOV R2, #0x10000
0000 032E F8C3 250C STR R2, [R3, #+0x50C]
0000 0332 E7ED B #-0x26 ;<bsp_board_init>+0x4 ;310
}
///////////////////////////////////////4////////////////////////////////////////
__STATIC_INLINE void nrf_gpio_cfg(
uint32_t pin_number,
nrf_gpio_pin_dir_t dir,
nrf_gpio_pin_input_t input,
nrf_gpio_pin_pull_t pull,
nrf_gpio_pin_drive_t drive,
nrf_gpio_pin_sense_t sense)
{
NRF_GPIO_Type * reg = nrf_gpio_pin_port_decode(&pin_number);
reg->PIN_CNF[pin_number] = ((uint32_t)dir << GPIO_PIN_CNF_DIR_Pos)
| ((uint32_t)input << GPIO_PIN_CNF_INPUT_Pos)
| ((uint32_t)pull << GPIO_PIN_CNF_PULL_Pos)
| ((uint32_t)drive << GPIO_PIN_CNF_DRIVE_Pos)
| ((uint32_t)sense << GPIO_PIN_CNF_SENSE_Pos);
}
////////////////////////////////////////5///////////////////////////////////////
__STATIC_INLINE void nrf_gpio_port_out_clear(NRF_GPIO_Type * p_reg, uint32_t clr_mask)
{
p_reg->OUTCLR = clr_mask;
0000 0326 F44F 3280 MOV R2, #0x10000
0000 032E F8C3 250C STR R2, [R3, #+0x50C]
0000 0332 E7ED B #-0x26 ;<bsp_board_init>+0x4 ;310
}
/*
* bsp_board_init is located at 0x30C but when executing the branch command
* it go to Reset_Handler
*/
/////////////////////////////////////////6//////////////////////////////////////
Reset_Handler:
/* Loop to copy data from read only memory to RAM.
* The ranges of copy from/to are specified by following symbols:
* __etext: LMA of start of the section to copy from. Usually end of text
* __data_start__: VMA of start of the section to copy to.
* __bss_start__: VMA of end of the section to copy to. Normally __data_end__ is used, but by using __bss_start__
* the user can add their own initialized data section before BSS section with the INTERT AFTER command.
*
* All addresses must be aligned to 4 bytes boundary.
*/
ldr r1, =__etext
ldr r2, =__data_start__
ldr r3, =__bss_start__
////////////////////////////////////////////////////////////////////////////////
Where did you find all the register references, such as
0000 030C 07C2 LSL R2, R0, #31
0000 030E D407 BMI #+0x0E ;<nrf_gpio_cfg> ;320
?
Are you sure they are correct for Nordic?
They are not part of the SDK functions that you refer to.
all register references are taken from Ozone
So it doesn't look like that in your application project?
So it doesn't look like that in your application project?
Hello, Ozone is the debugger I use, I attach the file .out of my application and the processor used so it know all registers and instruction to execute. So I think it should be related to my application
I don't need the .out file. What I am interested in is the files that you used when you compiled your project. main.c, boards.h and those files. When you debug, you should be able to step through the code from these files. Where does the issue occur in that case? In one of your earlier replies, you had a screenshot from your call stack that was stuck in the reset handler. What are the calls before that? Can you give me the screenshot of the entire table?
We succeed to program the NRF52 by updating the firmware of the STK3600 (the board we use to do flashing), you can close this issue.
Thanks