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 !
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?
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?
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