Problem with getting started with software development on nRF52805

[Lorenzo]

Hello,

I started working with microcontrollers recently, I'm having issues with getting started with software development on an MS46SF11 module from Minew based on the nRF52805 SoC.

My current setup consists of
SES IDE (downloaded through nRF Connect) on Windows 10
Minew MS46SF11 modules
nRF52 DK for programming and debugging (through the P20 connector, connected accordingly to the following schematics)

I need two nRF52 modules to communicate with each other using simple text strings that are fetched and returned from/to another microcontroller through serial communication, we have been advised to reprogram the module to use the ESB protocol.

Being new to this I decided to try implementing serial communication as a first attempt.
So I opened the UART example project (pca10040) from the nRF5 SDK with SES, changed the RX and TX pins in the UART configuration function following Minew's pinout for the module, changed the target to nRF52805 in the project's options, and tried to flash it on the Minew module, but it looks like I can only make it work on the DK.

Also debugging seems possible only if I'm using the DK alone.
If I'm using the Minew module attached to the P20 connector and I try placing a breakpoint inside the main() function the code never stops. It works instead (as expected) on the DK.

It looks like though, that the Minew module has been flashed with something since I can't see it anymore with my phone.

I was wondering if example projects that can work on modules like Minew's instead of DKs are available or if I missed documentation on how to convert the example projects that are inside the SDK in order to make them work on external modules.

[Kenneth]

Hi,

Can you try to run 'nrfjprog --eraseall' from command line tool? I am suspecting there is some data that is not erased.

Also, make sure that you add a pull-up on the RXD line to avoid floating input, framing error and assert. However I do not see how this should affect your code from not running.

Kenneth

[Lorenzo]

Hello,

I tried running the command, but I'm afraid the thing is bigger than that.

I was able to find this guide Developing for the nRF52805 with nRF5 SDK and tried following it, but it looks like there are issues with the 17.0.2 version of the SDK.

As user timuser said it would be great if it was possible to have just a simple working blinky/Hello World example natively made for nRF52805 that we can use as a starting point to build on.

Lorenzo

[AGarcia]

Hi there, I had the same problem that you had, I change it in the code: "__RAM1_segment_end__" to "__RAM_segment_end__" in the 

"ses_startup_nrf_common.s" file and it compiled correctly, however when I tried to download it to the target I get an error "Additional Load File [0]"

[Kenneth]

Likely related to this one:
https://devzone.nordicsemi.com/f/nordic-q-a/67755/i-would-like-to-know-why-the-error-__ram1_segment_end___-is-output

Kenneth

[Lorenzo]

I tried applying the same fix mentioned by AGarcia and got the same error message:

Seems like SES is looking for the softdevice in the wrong directory, but it's not possible to see the complete path.

Lorenzo

[Vidar Berg]

Hello,

It's attempting to load Softdevice version v.7.0.1, but nRF5 SDK 17.0.2 does not include this Softdevice version, so maybe that explains why it's not found?

It should look like this if you are using SDK 17.0.2:

[Lorenzo]

Thanks, I was finally able to build the project and flash my external board.

I proceeded to try building the uart example from the SDK again by replacing the main.c file in the working project I had just built.
Debugging now works as intended, but I can't see any of the characters that I try to send using the app_uart_put function on the serial monitor.

The USB/UART board I'm using has 2 LEDs that light up when something is transmitted or received, only the TX one lights up which should mean nothing gets written on the TX pin.

I checked the wiring and if I had followed the pinout correctly, but I can't see any issues.

Am I using the put function the wrong way?

Lorenzo

[Kenneth]

Which pins have you used for TX and RX? 

Have you tried adding a pull-up on the RX?

A logic analyzer trace could be helpful, in case it's a mismatch in the the voltage or baud rate.

Kenneth

[Lorenzo]

I have used pins 8 (21) and 9 (18) following the pinout from Minew

I set the baud rate to 2400 (but also tried leaving it to 115200 like the original code)

While debugging I can see the exact characters I send to the module through HTerm, by stopping the code when app_uart_get gets executed

Did you mean adding a pull-up on the TX on the custom board? (Or on the RX on the USB/UART board?) Minew's module can receive the data just fine, I can't seem to be able to send anything from it

What I tried doing was sending a character by using "app_uart_put('A');", but I wasn't completely sure about it as it seemed too easy

Lorenzo

[Kenneth]

Lorenzo said:

What I tried doing was sending a character by using "app_uart_put('A');", but I wasn't completely sure about it as it seemed too easy

That should work, have you tried a different pin for test? Looked at the pin on a logic analyzer?

Kenneth

[Lorenzo]

We don't have a logic analyzer, but luckily it wasn't necessary.
I tried using pin 14 (16) as the TX pin and I was able to receive the data I sent using the app_uart_put function, also printfs seem to work.
I will investigate the reason why the other pin wasn't working.

Since the uart functions let me send or receive one byte at a time I suppose that if I need to receive a string (e.g. "<2350>") I should then write a function that takes the single bytes and puts them in a char array so I can use it as a string, right?

Lorenzo

[Kenneth]

Lorenzo said:

Since the uart functions let me send or receive one byte at a time I suppose that if I need to receive a string (e.g. "<2350>") I should then write a function that takes the single bytes and puts them in a char array so I can use it as a string, right?

For app_uart_put() that is the case yes, though there should be other UART libraries that can be more efficient in this regard, e.g. libuarte:
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/lib_libuarte.html