Hi, just a follow up on this problem.
It looks like this was caused by a bug in my app. A recent update was
causing it to write to an array past it's upper bound.
David.
On Wed, Mar 26, 2008 at 10:02 AM, David <[EMAIL PROTECTED]> wrote:
> Hello, tinyos developers.
>
> (I don't think the regular tinyos users can answer this question).
>
> I have a tinyos 2.x app which uses LogRead.read() and
> LogWrite.append() fairly extensively. After a few minutes,
> LogRead.read() starts failing, but LogWrite.append() (seemingly)
> succeeds.
>
> My app does have logic to prevent using the flash log while another
> operation is still in progress, but it could be buggy.
>
> I updated Stm25pLogP.newRequest (called by Stm25pLogP.Read.read) so it
> calls printf() to display the current log state (was it still busy
> doing something when I made a request?).
>
> Here is my updated version:
>
> error_t newRequest( uint8_t client ) {
>
> if ( m_log_state[ client ].req != S_IDLE ) {
> printf("s: %d\n", m_log_state[ client ].req);
> printf("s: %d,%d,%d,%d,%d,%d\n", S_IDLE, S_READ, S_SEEK,
> S_ERASE, S_APPEND, S_SYNC);
> return FAIL;
> }
>
> call ClientResource.request[ client ]();
> m_log_state[ client ] = m_req;
>
> return SUCCESS;
>
> }
>
> When read() starts failing, I (always) get this output from the printf lines:
>
> s: 154
> s: 0,1,2,3,4,5
>
> The second line makes sense. This is the set of possible flash request
> states. The first line, with the current request state, 154, is
> confusing.
>
> I think it must be caused by a bug somewhere in Stm25pLogP, but it's
> possible that the 'req' field could legitimately have a value of 154.
> Any comments? Should I forward an example app which demonstrates this
> problem?
>
> In the meanwhile I will attempt to debug the Stm25pLogP module. I will
> forward any patches etc.
>
> David.
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
