[nRF52811] two way UART connection

RE: [nRF52811] two way UART connection

slid_daaviet — Mon, 25 Oct 2021 13:51:24 GMT

I wasn't testing a debug build😅. When debugging, I select the app_error_handler function to get the p_file_name value:

Then I check the string pointed by p_file_name using watch, and got this:
Interest fact: when I set NRF_LOG_ENABLE to 1, build and start debugging, the program gets stuck in "running..." at app_fifo_get()

RE: [nRF52811] two way UART connection

Einar Thorsrud — Mon, 25 Oct 2021 13:42:34 GMT

Hm, no. No idea, to be honest. Are you testing a debug build? And can you show how you found the value 0x20005f28?

RE: [nRF52811] two way UART connection

slid_daaviet — Mon, 25 Oct 2021 13:38:25 GMT

I get an "L". I can't find what it means. Any idea? (sorry for so many questions)

RE: [nRF52811] two way UART connection

Einar Thorsrud — Mon, 25 Oct 2021 13:27:32 GMT

Hi,

This is within the RAM of the nRF51811 so I am not sure why SES restricts this. You can turn of restrictions though, from project options under Debug -> Debugger. There set "Restrict Memory Access" to "No". Does that help?

Updat: Just to be sure, make sure you test a debug project, so that DEBUG is defined. That is needed for this information to be part of the build.

RE: [nRF52811] two way UART connection

slid_daaviet — Mon, 25 Oct 2021 13:00:05 GMT

Instead of pointing to a file, it says "Restricted memory range". Have you any idea what it means?

RE: [nRF52811] two way UART connection

Einar Thorsrud — Mon, 25 Oct 2021 11:53:05 GMT

Hi,

p_file_name is a pointer to a string that shows the file name where the error was detected by an APP_ERROR_CHECK. If you enable logging it is printed directly. If not, you can inspect it with a debugger. Remember to first make a debug build as that makes this much easier (the C code you see then matches the machine code). Then inspect for instance like this if using SES:

Add p_info to watch
Read the value of p_file_name wihin p_info
Type inn (char*)<value of p_file_name> as an expression

then you can read the value of the string like this:

RE: [nRF52811] two way UART connection

slid_daaviet — Mon, 25 Oct 2021 11:20:23 GMT

If I enable the DEBUG flag, app_error_handler function is called. It has an error code, a p_file_name and line_num, how can I interpret the hexadecimal value of p_file_name to locate the error?

RE: [nRF52811] two way UART connection

slid_daaviet — Mon, 25 Oct 2021 10:56:09 GMT

[quote userid="7377" url="~/f/nordic-q-a/80781/nrf52811-two-way-uart-connection/335648#335648"]There was a problem with the link to the example you are using. Can you post it again?[/quote]

It's this UART example.

[quote userid="7377" url="~/f/nordic-q-a/80781/nrf52811-two-way-uart-connection/335648#335648"]I see. What did you do to debug? The APP_UART_FIFO_INIT() essentially created two static buffers, and then calls app_uart_init(). If there is an issue, that should return an error code.[/quote]

If I am correct, it appears to occur when app_uart_get() is called. Then uart_event_handler is called, which in turn calls app_error_handler_bare. Depending on the breakpoints I use, app_error_handler_bare receives an error code of either 0x00000004 or 0x0000000c, which according to nrf_error.h correspond to "No Memory for operation" and "Data size exceeds limit" respectively.

[quote userid="7377" url="~/f/nordic-q-a/80781/nrf52811-two-way-uart-connection/335648#335648"]This is to aid debugging. It breaks on error, and then you can inspect with a debugger. What error code was returned from where? As you point to APP_UART_FIFO_INIT I assume you see it is from app_uart_init()? You may be interested in An introduction to error handling in nRF5 projects.[/quote]

Ah I see. I'll read up on that, thanks.

RE: [nRF52811] two way UART connection

Einar Thorsrud — Mon, 25 Oct 2021 08:03:00 GMT

Hi,

[quote user="slid_daaviet"]I have tried adapting this example to the nRF52811, without success so far.[/quote]

There was a problem with the link to the example you are using. Can you post it again?

[quote user="slid_daaviet"]I think the problem is in the APP_UART_FIFO_INIT function[/quote]

I see. What did you do to debug? The APP_UART_FIFO_INIT() essentially created two static buffers, and then calls app_uart_init(). If there is an issue, that should return an error code.

[quote user="slid_daaviet"]because there is a call to the app_error_handler funcion and NRF_BREAKPOINT_COND is activated.[/quote]

This is to aid debugging. It breaks on error, and then you can inspect with a debugger. What error code was returned from where? As you point to APP_UART_FIFO_INIT I assume you see it is from app_uart_init()? You may be interested in An introduction to error handling in nRF5 projects.

RE: [nRF52811] two way UART connection

slid_daaviet — Fri, 22 Oct 2021 15:37:28 GMT

Thanks for the help. I have tried adapting this example to the nRF52811, without success so far. I think the problem is in the APP_UART_FIFO_INIT function, but can't even debug it correctly, because there is a call to the app_error_handler funcion and NRF_BREAKPOINT_COND is activated. It's probably a vague problem description, but that's what I know so far...

RE: [nRF52811] two way UART connection

Einar Thorsrud — Tue, 19 Oct 2021 12:24:26 GMT

Hi,

[quote user="slid_daaviet"]Thanks for the tip, but that example is for UART over BLE, which is not exactly what I'm looking for.[/quote]

Yes, but the thing is that the example implements UART bridging over BLE (so both physical UART and NUS). If you ignore the BLE/NUS part, you are left with a simple example of using plain UART without the added complexity of the logger library. You can also refer to the UART example for something similar.

[quote user="slid_daaviet"]So, I am already receiving data from the nRF52811, but I would like to just send data through that serial port from the PC to the nRF52811.[/quote]

I see. The easiest way is to refer to one of the examples mentioned above, which implements bidirectional UART communication.

RE: [nRF52811] two way UART connection

slid_daaviet — Tue, 19 Oct 2021 11:56:42 GMT

Hi,

Thanks for the tip, but that example is for UART over BLE, which is not exactly what I'm looking for. Actually, the nRF52811 is connected to an nRF52840 that is used as a bridge (for flashing the code and reading data), which is turn is connected to the PC via a usb cable. When I plug in the usb cable, a serial port is opened and I am reading that port. So, I am already receiving data from the nRF52811, but I would like to just send data through that serial port from the PC to the nRF52811.

RE: [nRF52811] two way UART connection

Einar Thorsrud — Mon, 18 Oct 2021 17:12:54 GMT

Hi,

The CLI interface can be used for anything, not just control logging (see for instance the crypto CLI example). It is a bit complex though, so an alternative could be to skip the logger module altogether (including CLI) and use a simpler UART library for your UART communication. See for instance how physical UART is used in the NUS example.

RE: [nRF52811] two way UART connection

slid_daaviet — Mon, 18 Oct 2021 15:01:10 GMT

Just to clarify, I really just want to be able to send bytes via UART and have them be read by the nRF52811. With that working, I can then design my own protocol that interprets the command bytes

RE: [nRF52811] two way UART connection

slid_daaviet — Mon, 18 Oct 2021 14:10:08 GMT

From what I can understand, CLI Interface allows to control logger parameters, but what if I want to control radio features, e.g stop transmission, or change gpio pins?

RE: [nRF52811] two way UART connection

Einar Thorsrud — Mon, 18 Oct 2021 11:46:14 GMT

Hi David,

Are you using the logger module in the nRF5 SDK? If using a recent nRF5 SDK versions and the logger module, you can consider the CLI interface. Older nRF5 SDK versions also had a method for reading back simple characters without using the CLI (using NRF_LOG_GETCHAR()), but that was removed in SDK 15.0.0.

Einar