Streams interleaving/contaminating

[Tabulous]

Hi
ive got an issue where by im getting modem AT command data getting in to a data file that is written to file.
The system runs FatFS over SPI-FLASH (writes are very low frequency), the modem sits on a UART, but also the modem commands are echo'd over a debug UART too.


What happens is when the software does its background polling to check the modem staus, if it is currently writing a file then the AT command can end up in the file records, see below.....

correct record
I:1,16,-1

record with AT commands in it. i.e. AT+CSQ
I:1,A1T6+,C-S1Q

So either the debug or modem uart streams seem to be contaminating the file stream.

The file write uses chsnprintf to format the records.

Just wondered if this had been experienced before, and how to debug it ?

[Giovanni]

Hi,

Never seen this, are you using the Serial or UART driver? which version?

The input buffer looks interleaved not overwritten, very strange. Are you sure that the incoming data is correct? interleaving could occur before.

Giovanni

[Tabulous]

Serial devices are used.

Yep as you spotted the at commands dont over write, they are interleaved, which is very weird.....

Kernel version is 3.1.5

The call to chsnprintf is used to format the string, this is then used in the FatFS f_write call.

What i dont know, is the erroneous data been added before the f_write or after whilst progressing down the layers to the SPI driver and then on the SPI flash chip.

[Giovanni]

You could verify if the string is interleaved already in the serial driver input buffer or if it happens later.

Giovanni

[Tabulous]

If a threads stack is too small, is it possible for the thread to start overwriting other parts of memory ?

I know there are defines for CH_DBG_ENABLE_STACK_CHECK etc which i have all switched on, but just wondering if this is something that could happen ?

This issue might be down to a binary semaphore that is not protecting the single access of the modem. Thus is the semaphore getting corrupted some how.....

[Giovanni]

It could happen, I would first verify if the incoming data is what you expect.

Giovanni

[Tabulous]

going to ask this and i'll probably answer my own question.

I have a semaphore declared like so and init to count of one, so a binary semaphore;

semaphore_t sLock;

chSemObjectInit( &sLock, 1 );


I had a loop that was in error calling this repeatedly

chSemSignal( &sLock );

What i found was that, the under lying s_cnt was forever ever increasing.....
Is this what you would expect ? or as it was initialized as 1, was it not protected ?

[Giovanni]

It is expected, counter semaphores are supposed to count. You need a binary semaphore in that case, bsems can be signaled indefinitely.

Giovanni

[Tabulous]

It is expected, counter semaphores are supposed to count. You need a binary semaphore in that case, bsems can be signaled indefinitely.

Giovanni

I agreed, but if they are initialized with a count of 1, then surely counting more than this is an error......

[Giovanni]

It is not allowed to count to more than 1, there is a check.

Giovanni