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 ?
Streams interleaving/contaminating
Moderators: RoccoMarco, lbednarz, utzig, tfAteba, barthess
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Streams interleaving/contaminating
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
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
Re: Streams interleaving/contaminating
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.
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
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Streams interleaving/contaminating
You could verify if the string is interleaved already in the serial driver input buffer or if it happens later.
Giovanni
Giovanni
Re: Streams interleaving/contaminating
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.....
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
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Streams interleaving/contaminating
It could happen, I would first verify if the incoming data is what you expect.
Giovanni
Giovanni
Re: Streams interleaving/contaminating
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 ?
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
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Streams interleaving/contaminating
It is expected, counter semaphores are supposed to count. You need a binary semaphore in that case, bsems can be signaled indefinitely.
Giovanni
Giovanni
Re: Streams interleaving/contaminating
Giovanni wrote: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
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Streams interleaving/contaminating
It is not allowed to count to more than 1, there is a check.
Giovanni
Giovanni
Who is online
Users browsing this forum: No registered users and 49 guests