nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

RK — Tue, 21 Jul 2015 11:07:55 GMT

That would be useful - since putting memory pointers in registers is 'new' for the nRF52 it's possible other people will fall over something similar.

I need to go take another crack at getting the nordic stuff compiled with clang. I like clang, it optimizes well and it's got great ARM support (thanks to Apple). However it compiles the SVC softdevice code entirely broken and I haven't come up with a way to sort that out yet. That's another 'implementation dependent' thing.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

FormerMember — Tue, 21 Jul 2015 10:50:01 GMT

Thanks a ton for following up with the question and diving so deep for this. And even though there are some bits of unanswered parts, I guess we can rest in peace that this should bother any driver implementations.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

Susheel Nuguru — Tue, 21 Jul 2015 10:34:44 GMT

I agree, i do not think that it is going to be a big problem and it was good exercise. What is still unanswered is about the piece of assembly we add in end which makes compiler allocate space. I see that you have asked that question but still remain unexplained.

I will ask this information to be very visible in the migration guide from nRF51 to nRF52

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

RK — Tue, 21 Jul 2015 10:22:25 GMT

And the answer - which I have come around to believing, is the code falls into 'implementation dependent' and gcc is within its rights to decide that string isn't used and remove it.

Since the code was a piece of test code and not something anyone would be likely to write for real, initialized string on the stack going to a register and then wait for it to clock out, I don't think it's going to be a huge problem. It was however an interesting intellectual exercise.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

FormerMember — Fri, 17 Jul 2015 15:13:41 GMT

Here is his question

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

Susheel Nuguru — Fri, 17 Jul 2015 15:00:23 GMT

Thanks RK for filing bug in GCC, can you point us to that GCC bug you filed. In case someone is aiming at you, then we can support you :) I do not believe that GCC will change anything or to that matter do not think that they will agree that it is a GCC bug. But we need some explanation of why it works if we change [] to *, or adding some asm in the end. Because we want to know why GCC thinks these two are different. That explanation is the best outcome I expect from this

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

FormerMember — Fri, 17 Jul 2015 14:36:30 GMT

So, I was testing the simplified code that Aryan posted, which I modified a little. Now 'hello' gets printed only when at least one of the #if statement is '1' when the optimization level is O1 or greater. With O0 or Og, it works in any case.

It is strange that just adding a NOP before or after can change the way GCC initializes the string.

#include <stdbool.h>
#include <stdint.h>
#include "nrf_delay.h"
#include "nrf_gpio.h"
#include "nrf_clock.h"
#include "boards.h"
#include "nrf_uart.h"

int main(void)
{
    /* Configure TX and RX pins from board.h */
    nrf_gpio_cfg_output(TX_PIN_NUMBER);
    nrf_gpio_cfg_input(RX_PIN_NUMBER, GPIO_PIN_CNF_PULL_Disabled);
    NRF_UARTE0->ENABLE = (UARTE_ENABLE_ENABLE_Enabled << UARTE_ENABLE_ENABLE_Pos);
    NRF_UARTE0->PSEL.TXD = TX_PIN_NUMBER;
    NRF_UARTE0->PSEL.RTS = RX_PIN_NUMBER;

    nrf_gpio_cfg_output(RTS_PIN_NUMBER);
    nrf_gpio_cfg_input(CTS_PIN_NUMBER, GPIO_PIN_CNF_PULL_Disabled);
    NRF_UARTE0->PSEL.RTS = RTS_PIN_NUMBER;
    NRF_UARTE0->PSEL.CTS = CTS_PIN_NUMBER;
    NRF_UARTE0->CONFIG = (UARTE_CONFIG_HWFC_Enabled << UARTE_CONFIG_HWFC_Pos);

    /* Configure other UART parameters, BAUD rate is defined in nrf52-uart.h    */
    NRF_UARTE0->BAUDRATE = (UARTE_BAUDRATE_BAUDRATE_Baud460800 << UARTE_BAUDRATE_BAUDRATE_Pos);

    while(true) 
    {

	nrf_delay_ms(1000);

#if 1
	volatile
#endif 
	uint8_t str[] = "hello\n";
	uint32_t len = 6;

#if 0		//Pre NOP
        register uint32_t delay asm ("r0") = 1;
    __ASM volatile (
          " NOP"
           : "+r" (delay)); 
#endif
        NRF_UARTE0->TXD.PTR = (uint32_t)((uint8_t *) str);
        NRF_UARTE0->TXD.MAXCNT = (uint32_t) len;

        NRF_UARTE0->TASKS_STARTTX = 1;
        NRF_UARTE0->EVENTS_ENDTX = 0;
        while((0 == NRF_UARTE0->EVENTS_ENDTX));

#if 0		//Post NOP
        register uint32_t delay1 asm ("r0") = 1;
    __ASM volatile (
          " NOP"
           : "+r" (delay1)); 
#endif
    }
}

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

FormerMember — Fri, 17 Jul 2015 12:29:38 GMT

RK, I like your Yoda sentence 'Bug should I file?' :) I'm glad to have been at least the spark in finding a bug in GCC.

I don't have any issue now because the code in my question is just when I was playing around to understand the UARTE peripheral. Now I have made a ping-pong buffers based driver and It works well. I'll make it open source in a few days.

In any case I'll do the tests that you suggested in some time. And I'll play around seeing how this will affect the original issue, i.e. it working only when there is some UARTE register read or delay after the while loop waiting for EVENT_ENDTX.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

RK — Fri, 17 Jul 2015 11:49:00 GMT

I went to file this as a bug against ARM GCC to find you it's 'highly recommended' to ask a question in the answers section before filing a new bug, so I've done that. I will now probably get my head shot off by the GCC C-heads for writing invalid C, but that's life.

Prithvi - I've been working on this at the asm level, not actually testing it - can you try

changing the uint8_t[] to a char * pointer
alternatively adding 'volatile' to that uint8_t[] str pointer (although that' stupid"

and seeing if that actually also works around your underlying issue as well as doing the reads does? I'm concerned that we may have found an issue, but that may not actually be your issue!

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

Susheel Nuguru — Fri, 17 Jul 2015 06:46:50 GMT

I meant to ask if it did the same on Cortex-M0, because we tell the gcc compiler about the cpu explicitly I just verified it and it does the same thing. I tested it with this code on nRF51 (cortex-M0)

int main(void)
{
    char str[] = "hello\n";
    NRF_UART0->TXD = (uint32_t)str;
}

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

RK — Fri, 17 Jul 2015 06:31:22 GMT

No it doesn't end up in flash. It doesn't end up anywhere in the binary. And apart from that you can see it's not loaded and the SP is what's set into the tx ptr uninitialized.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

RK — Fri, 17 Jul 2015 06:29:29 GMT

There's no NRF dependency in the code at all, neither 51 nor 52. It would do the same on either. However the 51 doesn't have data pointers for uart, just a Tx register which takes a byte, so there's not an equivalent case. I don't know if it's a bug. The register is defined as volatile uint32, I don't know what inference it's allowed to draw about the use of data passed to it. I suspect if we report it as a gcc bug someone may explain why initializing stack based strings and passing them to registers is undefined behavior. It's odd that char*works but char[] doesn't.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

Krzysztof Chruscinski — Fri, 17 Jul 2015 06:27:54 GMT

DIdn't read all, but isn't it possible that "hello" ends up in flash? UARTE can work only on RAM data locations.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

Susheel Nuguru — Fri, 17 Jul 2015 06:11:09 GMT

Excellent, we are getting close. Did you see if this behavior is same with GCC on nRF51? If not then GCC is not following standard on one of them. Sounds like a bug

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

RK — Fri, 17 Jul 2015 05:27:34 GMT

Not really an answer but the comments are too restricted.

I have a shorter version which exhibits the same optimisation 'issue'

#include <stdint.h>

struct UART
{
    __volatile uint32_t padding[200];
    __volatile uint32_t TXD;
};

#define NRF_UARTE0 ((struct UART*)0x40002000)

int main(void)
{
    char str[] = "hello\n";
    NRF_UARTE0->TXD = (uint32_t)str;
}

when compiled main looks like this

00000000 <main>:
   0:   4b03            ldr     r3, [pc, #12]   ; (10 <main+0x10>)
   2:   b082            sub     sp, #8
   4:   2000            movs    r0, #0
   6:   f8c3 d320       str.w   sp, [r3, #800]  ; 0x320
   a:   b002            add     sp, #8
   c:   4770            bx      lr
   e:   bf00            nop
  10:   40002000        .word   0x40002000

What's happening is space is reserved on the stack for 'str' and that address is put into TXD but it's never initialised with 'hello\n"

An easy workaround is to change char str[] = "hello\n"; to char *str="hello\n";, then the output looks like this (making the variable volatile does the same thing)

00000000 <main>:
   0:   4b02            ldr     r3, [pc, #8]    ; (c <main+0xc>)
   2:   4a03            ldr     r2, [pc, #12]   ; (10 <main+0x10>)
   4:   f8c3 2320       str.w   r2, [r3, #800]  ; 0x320
   8:   2000            movs    r0, #0
   a:   4770            bx      lr
   c:   40002000        .word   0x40002000
  10:   00000000        .word   0x00000000

The contents of the address at main+0x10 is fixed up at link time to point to the .rodata initialised string.

This is compiled at -Os however -O1 does the same (as does -O2).

So what appears to be happening is space is reserved for the string on the stack, but it's not initialised. If you make the string longer you get more space reserved (ie sub sp, #8 becomes sub sp, #).

If you call strlen() on it, it initialises the string properly. So gcc has decided that it needs to allocate space on the stack for the string, however the contents isn't used so it doesn't bother to initialise it. This may or may not be related to how the register is defined at uint32_t but changing it around hasn't helped.

Is this a gcc bug? If it is it's not recent, I tried it with last year's Q1 release and it's still there. I think it's a bug myself and the memory should be initialised but there may be some bizarre C rule I don't know which makes that code undefined and allows the compiler to make the choice it does.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

Susheel Nuguru — Thu, 16 Jul 2015 15:17:01 GMT

just copy the code from my comments to blinky main.c file in nRF52 SDk and use the existing makefile. It took me a lot of time to narrow it down to that single ASM r0 write and the compiler go bananas without it : )

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

RK — Thu, 16 Jul 2015 14:17:58 GMT

s'ok - I can work through this as it is, would be good if I could build it myself. I can see some odd differences already. The TX PTR is loaded from the contents of the SP, however in the asm version that's properly set up beforehand (see address 60: where it's copied from r2) but in the other version it's not set up at all as far as I can tell, so it should have random garbage in it. There's also no link to the string at the end of the assembly (that word at 0x88 in the asm version but missing from the other version), so yes it seems it was optimised out. However the registers are still written so .. currently making no sense at all.

And why the addition of the r0 asm in there makes a difference is currently also beyond me.

Will look some more, perhaps I'll see if I can set up a makefile and build it too.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

Susheel Nuguru — Thu, 16 Jul 2015 14:01:27 GMT

do not have ELF, i have been on this for long time. Take rest and we can help Prithvi tomorrow.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

RK — Thu, 16 Jul 2015 13:45:18 GMT

I"ll look - possibly in the morning as it's getting a bit late here now and I've been staring at this for a while. Do you happen to have the two .elf files for those as well as the disassembly? They'll have even more information about where the strings are stored and I can stuff them through Hopper. If not, no problem, I really need to get my nrf52 environement properly set up so I can compile this stuff.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

Susheel Nuguru — Thu, 16 Jul 2015 13:38:19 GMT

If this ASM dump makes any sense, this has to be with GCC, Now the code i pasted works exactly like what Prithviraj sees.

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

Susheel Nuguru — Thu, 16 Jul 2015 13:31:18 GMT

RK, you can probably help me out here I have made this code simple

#include <stdbool.h>
#include <stdint.h>
#include "nrf_delay.h"
#include "nrf_gpio.h"
#include "nrf_clock.h"
#include "boards.h"
#include "nrf_uart.h"

int main(void)
{
    /* Configure TX and RX pins from board.h */
    nrf_gpio_cfg_output(TX_PIN_NUMBER);
    nrf_gpio_cfg_input(RX_PIN_NUMBER, GPIO_PIN_CNF_PULL_Disabled);
    NRF_UARTE0->ENABLE = (UARTE_ENABLE_ENABLE_Enabled << UARTE_ENABLE_ENABLE_Pos);
    NRF_UARTE0->PSEL.TXD = TX_PIN_NUMBER;
    NRF_UARTE0->PSEL.RTS = RX_PIN_NUMBER;

    nrf_gpio_cfg_output(RTS_PIN_NUMBER);
    nrf_gpio_cfg_input(CTS_PIN_NUMBER, GPIO_PIN_CNF_PULL_Disabled);
    NRF_UARTE0->PSEL.RTS = RTS_PIN_NUMBER;
    NRF_UARTE0->PSEL.CTS = CTS_PIN_NUMBER;
    NRF_UARTE0->CONFIG = (UARTE_CONFIG_HWFC_Enabled << UARTE_CONFIG_HWFC_Pos);

    /* Configure other UART parameters, BAUD rate is defined in nrf52-uart.h    */
    NRF_UARTE0->BAUDRATE = (UARTE_BAUDRATE_BAUDRATE_Baud115200 << UARTE_BAUDRATE_BAUDRATE_Pos);

    uint8_t str[] = "hello\n";
    uint32_t len = 6;

    while(true) 
    {
        NRF_UARTE0->TXD.PTR = (uint32_t)((uint8_t *) str);
        NRF_UARTE0->TXD.MAXCNT = (uint32_t) len;

        NRF_UARTE0->TASKS_STARTTX = 1;
        NRF_UARTE0->EVENTS_ENDTX = 0;
        while((0 == NRF_UARTE0->EVENTS_ENDTX));
        register uint32_t delay asm ("r0") = 1;
    __ASM volatile (
          " NOP"
           : "+r" (delay));
    }
}

With flags -O3, If i remove the ASM in the last, then it writes some garbage. If i add that ASM it does not. The problem does not seem to be write buffer, looking into the generated ASM, it looks like GCC is optimizing away below when no asm is used

uint8_t str[] = "hello\n"; uint32_t len = 6;

I am attaching two assembly dump files with and without the ASM code in the last. With ASM, look that there are few extra instructions while assigning str = hello

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

RK — Thu, 16 Jul 2015 13:03:18 GMT

Aryan, I'm massively relieved if it's not a GCC bug so no need to apologise for that.

PS I don't know if you do this or not, you said that optimized gcc is hard to follow (and it is). I always compile optimised but still add full debug info, the code is still scrambled but at least it has source in it.

I've been looking at that code for a while and don't see what's wrong. Wondered if it could be due to the write buffer on the Cortex M4 delaying the TASKS_STARTTX=1 write and the while loop exiting instantly but that doesn't seem very likely. Have you tried setting EVENTS_TXSTOPPED to 0 explicitly before starting the transmission?

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

FormerMember — Thu, 16 Jul 2015 12:54:21 GMT

If you have other things to take care of, go ahead. As of now, I'm reading the EVENTS_ENDTX, just in case and it works. So, no problem. Having said that, it'll be good to get to the bottom of this. :)

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

Susheel Nuguru — Thu, 16 Jul 2015 12:50:38 GMT

Wait PrithviRaj, i have to test few more things I will have to update my answer

RE: nrf52832 uart tx works only with NRF_UARTE0 read after EndTx

FormerMember — Thu, 16 Jul 2015 12:47:58 GMT

Thanks a lot Aryan for taking the time and effort to investigate this. Ya, I realized that setting STOPTX to 0 is stupid. :) I'm running on Linux. This bug is getting stranger by the minute.