DK programs from SES but not nRF Connect

RE: DK programs from SES but not nRF Connect

Vidar Berg — Fri, 22 Dec 2023 07:48:05 GMT

I'm glad to hear you found the problem. Thanks for updating the thread with your findings.

RE: DK programs from SES but not nRF Connect

trackerfx — Fri, 22 Dec 2023 05:12:00 GMT

Success!

Removing those symbols and enabling the NRF_LOG_BACKEND_RTT got me on the right track. Turns out the code was getting stuck in the port event handler. The main issue was that we are using pin 6 as an input. Pin 6 is, by default, assigned to the UART TX. It was hard to find; I use the CMSIS Configurator and the UART pin assignment is not listed. I found the pin assignment in 2 places in the sdk_config.h file. Once I re-assigned the UART TX to another pin everything started working as expected.

Thanks for all your help!

RE: DK programs from SES but not nRF Connect

Vidar Berg — Tue, 19 Dec 2023 12:51:33 GMT

Since you are running the code on an actual 810, you should remove the following symbols:

Same as descbrided here: Transferring the project to nRF52810 hardware.

[quote user="trackerfx"]Unfortunately, something is still not right. We're advertising for about 20 seconds, sometimes less, before dropping off. I can begin the connection process anywhere in this timeframe but it will always fail and immediately drop off, requiring a reset of the board. Not having debug info is maddening.[/quote]

If you haven't done it already, I recommend enabling debug logging to see if it may reveal more details about why it is crashing. You can do so by setting NRF_LOG_ENABLED == 1 and NRF_LOG_BACKEND_RTT_ENABLED == 1 in sdk_config.h. You may also want to add 'DEBUG' to the list of pre-processor symbols for more verbose crash logs. The log should be displayed in the debug terminal when you start a debug session in Embedded Studio.

The issue is not necessarily related to the porting from 52840 to the nRF52810, but could be due to some other differences when going from a DK to a custom board that we've overlooked.

RE: DK programs from SES but not nRF Connect

trackerfx — Mon, 18 Dec 2023 23:02:12 GMT

Thanks for including those screenshots. Mine looks like that:

It seems we match. So strange.

Everything I've read says the 810 should be able to handle this project. The project uses the WDT, FLASH memory, 3 app timers, pin interrupts, and is set up as a BLE peripheral device. There's not much else to it. Unfortunately, this is my first time developing on the 840 just to port over to the 810. I had one other project that was to use the 810 but the limited pinout and lack of dedicated USB pins made us switch to the 840 very early. Building off of the ble_app_template example for this project made it easy, or so I thought. I just don't see what difference between the chips I'm not accounting for.

RE: DK programs from SES but not nRF Connect

trackerfx — Mon, 18 Dec 2023 17:23:20 GMT

My apologies, I should have been clearer. I'm just now discovering that the S112 softdevice will indeed run on the 840. Until now, I had been switching between S112 and S140 depending on the chip I was programming. Now I'm just using S112 for both chips and only the 810 RAM and FLASH placement settings. I've been programming the custom board with the 10040e output from my build. This seems to satisfy the requirements for the startup file, system file, and linker script. I'll look into 4 and 5 and report back.

RE: DK programs from SES but not nRF Connect

Vidar Berg — Mon, 18 Dec 2023 09:02:41 GMT

I assumed you were using the nRF52840 on your custom board as well, not the nRF52810. Porting a 52840 based project to the nRF52810 requires additional steps:

1. Adjust the FLASH and RAM sections in your linker script to match the 52810 variant.

2. Switch to a Softdevice variant that is qualified for the chip: SDKs and SoftDevices. This involves changing the Softdevice include paths and the application's start address in FLASH.

3. Change startup files (rename ses_startup_nrf52840.s to ses_startup_nrf52810.s and system_nrf52840.c to system_nrf52810.c)

4. Update preprocessor flags to match the chip variant.

5. Disable HW floating point support in the CPU.

I recommend using one of the 'pca10040e' projects as a reference. For instance, take a look at the ble_app_uart/pca10040e/s112/ses project.

RE: DK programs from SES but not nRF Connect

trackerfx — Sun, 17 Dec 2023 17:15:38 GMT

I dug a little deeper and found that the nRF52810 RAM section only goes up to 0x20006000. With that in mind and with some edits to the max MTU size I got the RAM placement to RAM_START=0x20001A50 which according to my math comes out to RAM_SIZE=0x45B0 for the 810. The DK still works fine with these parameters and now the custom PCB is blinking an LED and advertising.

Huzzah! Progress!

Unfortunately, something is still not right. We're advertising for about 20 seconds, sometimes less, before dropping off. I can begin the connection process anywhere in this timeframe but it will always fail and immediately drop off, requiring a reset of the board. Not having debug info is maddening.

RE: DK programs from SES but not nRF Connect

trackerfx — Sat, 16 Dec 2023 03:15:16 GMT

So, you're right about the debug option and it did turn out that there was a slight difference with the RAM placement in the project options with the debug version as opposed to the release version. Now that it's fixed, I can successfully program the DK board with either method. Still the same result with the custom PCB. It doesn't seem to be operating at all, no LED, no BLE, etc. I checked that the crystals are both there. I have a jumper across the selection pin and VCC as you suggested and can read back the data after programming and it identifies the connected nRF52810 and the presence of a softdevice after programming. I also tried programming the blinky example and the template example and in both cases the LED's operate and I can connect to it with the nRF Connect Bluetooth app. I don't think it's a hardware issue.

This brings me back to RAM placement; according to the datasheets it appears that the RAM section in question starts at the same address (0x20000000) for both chips. Is RAM_START=0x20002598 RAM_SIZE=0x3DA68 a problem for the 810? Those were the stated address and size that were suggested by the application when I was working with the 840. Are there any differences between the 840 and 810 that need to be accounted for other than the softdevice? I do write 12 bytes of data to the last page in flash, 0xFF for the 840 and 0x2F for the 810. I must be missing something.

RE: DK programs from SES but not nRF Connect

Vidar Berg — Fri, 15 Dec 2023 13:18:26 GMT

Hello,

I don't see any issues with the programming steps you have outlined. Does your board design include the optional DCDC inductors and the 32KHz crystal like the DK does? If not, have you configured the firmware so that it does not rely on these components? That is, have you selected the internal RC as the clock source and not enabled the DCDC regulator (Note: the DCDC regulator is not enabled by default in the nRF5 SDK)?

[quote user=""]When I add the softdevice and app, the custom board didn't respond. When I switched back to the S140 and DK board, programming with the Connect programmer resulted in strange behavior: button presses executing functions not assigned to them, missing nrf_log_info prints, etc. Apparently I'm doing something wrong.[/quote]

There's a hardware switch on the DK board that determines whether the SWD lines are routed to the onboard 52840 or to the debug out pins. Therefore, it should not make a difference whether you use the Programmer app or SES for programming. To ensure you don't mistakenly program the onboard chip, you can place a jumper on the pins shown below. With this configuration, you will get a programming error if the external board is not detected.

[quote user=""]When I switched back to the S140 and DK board, programming with the Connect programmer resulted in strange behavior: button presses executing functions not assigned to them, missing nrf_log_info prints, etc. Apparently I'm doing something wrong.[/quote][quote user=""]...\nRF5_SDK_17.1.0_ddde560\nRF5_SDK_17.1.0_ddde560\projects\Padlock\BLE_smartPadlock\pca10056\s140\ses\Output\Release\Exe\[/quote]

It was a bit difficult to see from your screenshot due to the low resolution, but it appears that you are building the project with the 'Debug' configuration. As a result, the generated hex file will be located in \Output\Debug\Exe, not in \Output\Release\Exe.

Best regards,

Vidar