NRF52832-QFAB-R loader script

[sboudaud]

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.

[Edvin]

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

[sboudaud]

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?

[sboudaud]

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?

[Edvin]

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?

[sboudaud]

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

[sboudaud]

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

[Edvin]

Is it the error handler that catches something? 

 

Edvin said:

Have you tried to monitor the log? 

[sboudaud]

The reset Handler is called: