nrf5x: Fix assert test on SERIAL_RESERVED_CHAR_MATCH

[andrewleech]

Description

I'm migrating an existing project to the recently-merged nrf52 / sdk 14.2 codebase in master.
I use a uart serial with match character for automatic depacketizing.

On current master I now get an assert fail as it's testing that char_match == SERIAL_RESERVED_CHAR_MATCH where I believe it should be the opposite; char_match should not be allowed to be SERIAL_RESERVED_CHAR_MATCH

This is with GCC and the debug.json build profile.

Pull request type

[X] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

[0xc0170]

I am not certain why it asserts even on the condition as it is ? As default value for char_match is this reserved character, thus if read without character match is used, then char_match contains reserved value (=not used) ?

[andrewleech]

Ah good point, perhaps this assert needs to be just removed entirely... I haven't checked if anything similar exists in the previous nordic platforms.

[0xc0170]

I think so. I understand the rest of the parameters there to be checked (not supported length , width etc) but asserting on char match does not make sense to me. Please verify

[marcuschangarm]

The assert is there to check that the default value (SERIAL_RESERVED_CHAR_MATCH) hasn't been changed.

[marcuschangarm]

I use a uart serial with match character for automatic depacketizing.

The new serial driver doesn't support character matching since reception is handled by DMA which only stops once the buffer is full.

[0xc0170]

That would explain that. No interrupt driver ? I would not expect to have DMA iwth character match thus if character match is selected, no dma involved ? Or that is also not possible thus that assert?

[marcuschangarm]

Everything goes through the DMA now - it is the only way to prevent data loss it is the only API supported by the UARTE peripheral. The DMA buffers are copied to an atomic fifo which getc reads from. Interrupts are generated when needed.

[andrewleech]

Oh, the character match was a killer feature for me. :-(
Well I guess I'll change this PR to add a comment to the assert to alert users like me why that assert is there.

Assuming there's still an interrupt available on each char received (?) I suppose I can add the char match back in my app.

[marcuschangarm]

Oh, the character match was a killer feature for me. :-(

Who do you think pushed for it initially? 😄 I didn't implement it since the DMA takes away the performance benefit and you already have the full buffer when you get the interrupt.

Assuming there's still an interrupt available on each char received (?) I suppose I can add the char match back in my app.

Yes, but the interrupt wont be per character but rather per full DMA buffer, which size you can configure.

[andrewleech]

Oh, this will be a really big problem for receiving variable sized messages.

My current project is porting from nrf51 to nrf52810, I'm working on filling out the 52810 support in mbed, it's a fantastic (cheap) chip.

It needs to be able to receive and handle messages between 2 character and 20 character long, with a null terminator on each one.
In fact most of my embedded projects have variable length usart messages where the length is either in the header of the message or a fixed end of message byte.

I've just been reading the uarte / easydma docs, I wasn't aware of it previously... I don't know how it's going to be possible to support variable length messaging... but yes I can see more the limitations and why you've implemented what you have!

[marcuschangarm]

Ah, sorry, there is a timeout to flush the buffer so even if you only get 1 character you'll still get the interrupt so it should be straight forward to handle variable length messages.

[andrewleech]

Oh really, I didn't see any reference to a timeout (haven't looked deep/close enough clearly).
Currently the sending device often has multiple messages back to back (which has caused missed messages on existing hardware) so my options are to make the other micro have fixed length or a reasonable timeout delay between each, either should be possible...
Thanks for the info!

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 1867
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6748/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 1514
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/6748/

[mbed-ci]

Test : FAILURE

Build number : 1678
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6748/1678

[0xc0170]

#6748 (comment)

@LMESTM The above failure, can you reproduce locally? I noticed it in the last days in some CI runs

/morph test
/morph mbed2-build

[mbed-ci]

Test : SUCCESS

Build number : 1684
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6748/1684

[marcuschangarm]

Currently the sending device often has multiple messages back to back (which has caused missed messages on existing hardware) so my options are to make the other micro have fixed length or a reasonable timeout delay between each, either should be possible...

I wouldn't do anything with the other micro just yet. There is a very generous (and configurable) atomic fifo between getc and the DMA buffers.

Once you get an interrupt, it is either because the DMA buffer is full or the other micro is done sending. Just read out all characters in the fifo whenever you get an interrupt and you shouldn't miss any data.