NRF52832-QFAB-R loader script

RE: NRF52832-QFAB-R loader script

sboudaud — Wed, 11 Dec 2019 16:58:26 GMT

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

RE: NRF52832-QFAB-R loader script

Edvin — Thu, 05 Dec 2019 10:30:52 GMT

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?

RE: NRF52832-QFAB-R loader script

sboudaud — Thu, 05 Dec 2019 09:57:21 GMT

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

RE: NRF52832-QFAB-R loader script

Edvin — Wed, 04 Dec 2019 15:35:22 GMT

So it doesn't look like that in your application project?

RE: NRF52832-QFAB-R loader script

sboudaud — Wed, 04 Dec 2019 15:08:21 GMT

all register references are taken from Ozone

RE: NRF52832-QFAB-R loader script

Edvin — Wed, 04 Dec 2019 10:03:12 GMT

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.

RE: NRF52832-QFAB-R loader script

sboudaud — Wed, 04 Dec 2019 09:41:58 GMT

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__
////////////////////////////////////////////////////////////////////////////////

RE: NRF52832-QFAB-R loader script

Edvin — Mon, 02 Dec 2019 14:59:14 GMT

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

RE: NRF52832-QFAB-R loader script

sboudaud — Mon, 02 Dec 2019 10:52:43 GMT

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 !

RE: NRF52832-QFAB-R loader script

sboudaud — Mon, 02 Dec 2019 09:30:23 GMT

The reset Handler is called:

RE: NRF52832-QFAB-R loader script

Edvin — Fri, 29 Nov 2019 10:00:58 GMT

Is it the error handler that catches something?

[quote user="Edvin Holmseth"]Have you tried to monitor the log? [/quote]

RE: NRF52832-QFAB-R loader script

sboudaud — Thu, 28 Nov 2019 15:59:41 GMT

To resume, the only way to start the application on my custom board is to do these steps:

1- flash the application

2- start the debugger (ozone)

3- remove connection with the debugger

4- remove the battery

5- reconnect the battery then it works

RE: NRF52832-QFAB-R loader script

sboudaud — Thu, 28 Nov 2019 15:34:21 GMT

I don't use log.

the parameters:

         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

clr_mask = 0x10000 => pin 16

p_reg->OUTCLR = 0x5000 0000 + 0x50C

RE: NRF52832-QFAB-R loader script

Edvin — Thu, 28 Nov 2019 08:39:25 GMT

I don't understand exactly why it stops there when you are debugging. Have you tried to monitor the log?

Do you know what parameters nrf_gpio_port_out_clear() was called with when it stopped?

RE: NRF52832-QFAB-R loader script

sboudaud — Wed, 27 Nov 2019 15:11:01 GMT

Hello

programming is not an issue, I use this: https://www.silabs.com/documents/public/user-guides/efm32lg-stk3600-ug.pdf

the kit is connected to SWIO et SWCLK of the nrf52 to perform the programming.

yes I did debug the application, I tried with the blinky example from peripheral under s10040/blank/armgcc as this is the simplest example. When I start debugging with Ozone I see that the nrf52 reset when it try to configure the PIN 16 (LED PIN in the custom board), exactly here:

__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
}

Then I removed the debugger connection with the custom board and removed the battery and plug it again to be sure that the device reset completely and then my board worked!

So I tried again to program the same example as usual :

$ nrfjprog --eraseall

$ nrfjprog -f nrf52 --program _build/nrf52832_xxaa.hex --sectorerase

$ nrfjprog --reset

the application don't start as usual so I unplug/plug the battery and the application don't start.

So I connected the debugger and start debugging and see the same result as before (reset when configuring pin 16), then when I removed the debugger connection and unplug/plug the battery the application started!! It seems like when I run the debugger it do something (I don't know what) that enable the application to start after !!

What is wrong in what I'm doing?

RE: NRF52832-QFAB-R loader script

Edvin — Tue, 26 Nov 2019 15:18:22 GMT

dud you succeed to debug the application? Do you have a programmer that you can use for this? How did you program your custom board?

BR,

Edvin

RE: NRF52832-QFAB-R loader script

sboudaud — Tue, 26 Nov 2019 13:45:24 GMT

Hello,

As my first goal is to check that our setup is good then test the currernt consumption, I made the following test:

1- I took the example peripheral/blinky tested on DK work fine

2- I added to the custom board a led connected to P0.16 (LED works fine when powered)

3- Modified blinky_gccnrf52.ld:

   MEMORY
   {
   FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x1a000
   RAM (rwx) : ORIGIN = 0x20002a98, LENGTH = 0x5568
   }

4- Modified the makefile to use new board name "BOARD_PCA10040_ABW"

=> Flashed soft device s132 and new application on our custom board but the led don't blink, and the current is 5mA more than it should.

5- I changed just the led number PIN to 17 and rebuild and flash it on the DK and it works

I feel like there is something that I have to change but I don't know where!

Please can you help as we are stuck and can't go further in the development?

RE: NRF52832-QFAB-R loader script

sboudaud — Tue, 26 Nov 2019 09:05:05 GMT

I tried to debug the app with ozone but the connection fail, I'm using leopard geko EFM32 development kit to connect to the BLE.

RE: NRF52832-QFAB-R loader script

sboudaud — Mon, 25 Nov 2019 13:56:02 GMT

Just to add I use SDK16

RE: NRF52832-QFAB-R loader script

sboudaud — Mon, 25 Nov 2019 13:52:12 GMT

Thanks Edvin for the response,

[quote userid="26071" url="~/f/nordic-q-a/54643/nrf52832-qfab-r-loader-script/221279"]it is probably because your custom board doesn't have an external LFXTAL. Do you have that? [/quote]

Yes we have LFXTAL 32kHz

I tried this config for the examples\ble_peripheral\ble_app_blinky (I removed all led and button management as our board don't use buttons and leds) :

MEMORY
{
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0x1a000
RAM (rwx) : ORIGIN = 0x20002a98, LENGTH = 0x5568
}

but the result is the same as above (device is not advertising) and the current consumption is high almost 5mA for the BLE (the board without BLE consume 4.2mA and with BLE 9.24mA)

maybe my issue is not there but I can't figure out where

our design:

RE: NRF52832-QFAB-R loader script

Edvin — Thu, 21 Nov 2019 10:23:33 GMT

Hello,

You should probably adjust the memory settings to match the chip variant that you have. Check this table:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcomp_matrix_nrf52832%2FCOMP%2Fnrf52832%2Fic_revision_overview.html

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