Non reproduceable reboots on 1.3H

[Daniel-378]

Hello everybody.

I'm a new Ethernut User, starting with Ethernut 1.3H. First of all let
me thank the developers of this project. It's a great thing to be able
to buy a complete embedded board with such a high developed operating
system and a large user API. I'm really impressed of Ethernut.

Nevertheless now the first problems rose up.

I've implemented a small sample for a webserver. It is based on the
"httpd" Sample.
In the "main" the app starts a thread, which handles HTTP Requests. This
thread redirects HTTP Queries via "NutHttpProcessRequest(stream)" to a
registered cgi-function.
Each time this function is called through a HTTP Request, some (9)
values are read from the EEPROM and sent as HTML-Page back to the
browser. The whole function is executed in approx. 700 - 800 ms.
Now I have the effect, that every 3-5 times I execute this function
either the board reboots or it stucks and I have to reboot it myself. I
cannot reproduce this behaviour. I logged the heap space and I think
it's enough free (20.000 bytes).

Do you have any experience in which situations the board reboots or get
stuck? I don't know in which direction I have to investigate. Maybe it's
a timing problem of concurring threads? But the cgi-function is the only
code that is executed.

Unfortunately a few weeks ago I connected the Analog Input in the wrong
way. It blews up the fuse and I'm not sure, that the hardware is fully O.K.

Best regards,
Daniel
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Daniel-378]

Hello again.

I have investigated a little further and found out, that when the
function stucks, it is always at EEPROM access.
Now I hab a look at the API sources. I saw that interrupts are not
disabled before EEPROM access. At other embedded boards one have to
disable all interrupts before EEPROM access and enable them afterwards.

Can you tell me if the EEPROM access is secured against this behaviour?

Best regards,
Daniel

Daniel schrieb:

> Hello everybody.
>
> I'm a new Ethernut User, starting with Ethernut 1.3H. First of all let
> me thank the developers of this project. It's a great thing to be able
> to buy a complete embedded board with such a high developed operating
> system and a large user API. I'm really impressed of Ethernut.
>
> Nevertheless now the first problems rose up.
>
> I've implemented a small sample for a webserver. It is based on the
> "httpd" Sample.
> In the "main" the app starts a thread, which handles HTTP Requests. This
> thread redirects HTTP Queries via "NutHttpProcessRequest(stream)" to a
> registered cgi-function.
> Each time this function is called through a HTTP Request, some (9)
> values are read from the EEPROM and sent as HTML-Page back to the
> browser. The whole function is executed in approx. 700 - 800 ms.
> Now I have the effect, that every 3-5 times I execute this function
> either the board reboots or it stucks and I have to reboot it myself. I
> cannot reproduce this behaviour. I logged the heap space and I think
> it's enough free (20.000 bytes).
>
> Do you have any experience in which situations the board reboots or get
> stuck? I don't know in which direction I have to investigate. Maybe it's
> a timing problem of concurring threads? But the cgi-function is the only
> code that is executed.
>
> Unfortunately a few weeks ago I connected the Analog Input in the wrong
> way. It blews up the fuse and I'm not sure, that the hardware is fully O.K.
>
> Best regards,
> Daniel
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>  

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Thiago A. Corrêa]

On Mon, Aug 31, 2009 at 8:24 AM, Daniel<ziu82@...> wrote:
> Hello again.
>
> I have investigated a little further and found out, that when the
> function stucks, it is always at EEPROM access.

Internal EEPROM? Or external?

> Now I hab a look at the API sources. I saw that interrupts are not
> disabled before EEPROM access. At other embedded boards one have to
> disable all interrupts before EEPROM access and enable them afterwards.
>
> Can you tell me if the EEPROM access is secured against this behaviour?

True, Atmel does recomends disabling interrupts while accessing the
eeprom (Not sure how if all access should be protected or only
writting). I haven't checked if ethernut does that, but I do that on
my own code before calling ethernut functions.

I never had a problem with the board rebooting, but I did with it
loosing it's eeprom contents, that's when I asked Atmel and added the
eeprom interrupt guard. But my problem wasn't solved by it, I just
left that in the code as precausion. The problem was power line noise
(industrial environment)

Kind Regards,
   Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Daniel-378]

Hi Thiago,

Thanks for the fast reply. It's the onboard eeprom.

You say "I haven't checked if ethernut does that, but I do that on my
own code before calling ethernut functions.". Can you tell me the
functions for disabling/enabling interrupts? I found nothing in the API.
So I can test if it works with disabled interrupts.

Best regards,
Daniel

Thiago A. Corrêa schrieb:

> On Mon, Aug 31, 2009 at 8:24 AM, Daniel<ziu82@...> wrote:
>  
>> Hello again.
>>
>> I have investigated a little further and found out, that when the
>> function stucks, it is always at EEPROM access.
>>    
>
> Internal EEPROM? Or external?
>
>  
>> Now I hab a look at the API sources. I saw that interrupts are not
>> disabled before EEPROM access. At other embedded boards one have to
>> disable all interrupts before EEPROM access and enable them afterwards.
>>
>> Can you tell me if the EEPROM access is secured against this behaviour?
>>    
>
> True, Atmel does recomends disabling interrupts while accessing the
> eeprom (Not sure how if all access should be protected or only
> writting). I haven't checked if ethernut does that, but I do that on
> my own code before calling ethernut functions.
>
> I never had a problem with the board rebooting, but I did with it
> loosing it's eeprom contents, that's when I asked Atmel and added the
> eeprom interrupt guard. But my problem wasn't solved by it, I just
> left that in the code as precausion. The problem was power line noise
> (industrial environment)
>
> Kind Regards,
>    Thiago A. Correa
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>  

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Thiago A. Corrêa]

Hi,

On Mon, Aug 31, 2009 at 8:47 AM, Daniel<ziu82@...> wrote:
> Hi Thiago,
>
> Thanks for the fast reply. It's the onboard eeprom.
>
> You say "I haven't checked if ethernut does that, but I do that on my
> own code before calling ethernut functions.". Can you tell me the
> functions for disabling/enabling interrupts? I found nothing in the API.
> So I can test if it works with disabled interrupts.
>

NutEnterCritical and NutExitCritical disables and reenables
interrupts, respectively. I've wrapped my code between those calls.

Kind Regards,
   Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Daniel-378]

Hi,

Thiago, thanks for the answer. But this was not the problem.

For reading from eeprom i used following function:

void LoadEEString(int offset, int length, char* buffer)
{
    realloc(buffer, length+1);
    memset(buffer, '\0', length+1);

    // Load from EEPROM
    NutEnterCritical();
    NutNvMemLoad(offset, buffer, length);
    NutExitCritical();
    // Get sure that we can use the buffer for I/O functions
    buffer[length] = '\0';
}

With this implementation my function shows the strange behaviour and
stucks after 3-5 times called.

Now I stopped using "realloc" and everything works:

void LoadEEString(int offset, int length, char* buffer)
{
    // Load from EEPROM
    NutEnterCritical();
    NutNvMemLoad(offset, buffer, length);
    NutExitCritical();
    // Get sure that we can use the buffer for I/O functions
    buffer[length] = '\0';
}

Is there any know bug about "realloc" or do I have an error in usage of
this function?

Best regards,
Daniel

Thiago A. Corrêa schrieb:

> Hi,
>
> On Mon, Aug 31, 2009 at 8:47 AM, Daniel<ziu82@...> wrote:
>  
>> Hi Thiago,
>>
>> Thanks for the fast reply. It's the onboard eeprom.
>>
>> You say "I haven't checked if ethernut does that, but I do that on my
>> own code before calling ethernut functions.". Can you tell me the
>> functions for disabling/enabling interrupts? I found nothing in the API.
>> So I can test if it works with disabled interrupts.
>>
>>    
>
> NutEnterCritical and NutExitCritical disables and reenables
> interrupts, respectively. I've wrapped my code between those calls.
>
> Kind Regards,
>    Thiago A. Correa
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>  

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Coleman Brumley-3]

I don't think you were using realloc correctly.

Shouldn't that have been as follows?

void LoadEEString(int offset, int length, char* buffer)
{
    buffer = realloc(buffer,length+1);
    if(buffer)
    {
        memset(buffer,(char)0,length);
        // Load from EEPROM
        NutEnterCritical();
        NutNvMemLoad(offset, buffer, length);
        NutExitCritical();
        // Get sure that we can use the buffer for I/O functions
        buffer[length] = '\0';    
    }
}



- Coleman

> -----Original Message-----
> From: en-nut-discussion-bounces@... [mailto:en-nut-discussion-
> bounces@...] On Behalf Of Daniel
> Sent: Monday, August 31, 2009 11:00 AM
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] Non reproduceable reboots on 1.3H
>
> Hi,
>
> Thiago, thanks for the answer. But this was not the problem.
>
> For reading from eeprom i used following function:
>
> void LoadEEString(int offset, int length, char* buffer)
> {
>     realloc(buffer, length+1);
>     memset(buffer, '\0', length+1);
>
>     // Load from EEPROM
>     NutEnterCritical();
>     NutNvMemLoad(offset, buffer, length);
>     NutExitCritical();
>     // Get sure that we can use the buffer for I/O functions
>     buffer[length] = '\0';
> }
>
> With this implementation my function shows the strange behaviour and
> stucks after 3-5 times called.
>
> Now I stopped using "realloc" and everything works:
>
> void LoadEEString(int offset, int length, char* buffer)
> {
>     // Load from EEPROM
>     NutEnterCritical();
>     NutNvMemLoad(offset, buffer, length);
>     NutExitCritical();
>     // Get sure that we can use the buffer for I/O functions
>     buffer[length] = '\0';
> }
>
> Is there any know bug about "realloc" or do I have an error in usage of
> this function?
>
> Best regards,
> Daniel
>
> Thiago A. Corrêa schrieb:
> > Hi,
> >
> > On Mon, Aug 31, 2009 at 8:47 AM, Daniel<ziu82@...> wrote:
> >
> >> Hi Thiago,
> >>
> >> Thanks for the fast reply. It's the onboard eeprom.
> >>
> >> You say "I haven't checked if ethernut does that, but I do that on
> my
> >> own code before calling ethernut functions.". Can you tell me the
> >> functions for disabling/enabling interrupts? I found nothing in the
> API.
> >> So I can test if it works with disabled interrupts.
> >>
> >>
> >
> > NutEnterCritical and NutExitCritical disables and reenables
> > interrupts, respectively. I've wrapped my code between those calls.
> >
> > Kind Regards,
> >    Thiago A. Correa
> > _______________________________________________
> > http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> >
> >
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Daniel-378]

Hi Coleman,

After reading the API again, I see that you are right. I used the wrong
buffer.

Thanks for the correction.

Regards,
Daniel


Coleman Brumley schrieb:

> I don't think you were using realloc correctly.
>
> Shouldn't that have been as follows?
>
> void LoadEEString(int offset, int length, char* buffer)
> {
>     buffer = realloc(buffer,length+1);
>     if(buffer)
>     {
>         memset(buffer,(char)0,length);
>         // Load from EEPROM
>         NutEnterCritical();
>         NutNvMemLoad(offset, buffer, length);
>         NutExitCritical();
>         // Get sure that we can use the buffer for I/O functions
>         buffer[length] = '\0';    
>     }
> }
>
>
>
> - Coleman
>
>  
>> -----Original Message-----
>> From: en-nut-discussion-bounces@... [mailto:en-nut-discussion-
>> bounces@...] On Behalf Of Daniel
>> Sent: Monday, August 31, 2009 11:00 AM
>> To: Ethernut User Chat (English)
>> Subject: Re: [En-Nut-Discussion] Non reproduceable reboots on 1.3H
>>
>> Hi,
>>
>> Thiago, thanks for the answer. But this was not the problem.
>>
>> For reading from eeprom i used following function:
>>
>> void LoadEEString(int offset, int length, char* buffer)
>> {
>>     realloc(buffer, length+1);
>>     memset(buffer, '\0', length+1);
>>
>>     // Load from EEPROM
>>     NutEnterCritical();
>>     NutNvMemLoad(offset, buffer, length);
>>     NutExitCritical();
>>     // Get sure that we can use the buffer for I/O functions
>>     buffer[length] = '\0';
>> }
>>
>> With this implementation my function shows the strange behaviour and
>> stucks after 3-5 times called.
>>
>> Now I stopped using "realloc" and everything works:
>>
>> void LoadEEString(int offset, int length, char* buffer)
>> {
>>     // Load from EEPROM
>>     NutEnterCritical();
>>     NutNvMemLoad(offset, buffer, length);
>>     NutExitCritical();
>>     // Get sure that we can use the buffer for I/O functions
>>     buffer[length] = '\0';
>> }
>>
>> Is there any know bug about "realloc" or do I have an error in usage of
>> this function?
>>
>> Best regards,
>> Daniel
>>
>> Thiago A. Corrêa schrieb:
>>    
>>> Hi,
>>>
>>> On Mon, Aug 31, 2009 at 8:47 AM, Daniel<ziu82@...> wrote:
>>>
>>>      
>>>> Hi Thiago,
>>>>
>>>> Thanks for the fast reply. It's the onboard eeprom.
>>>>
>>>> You say "I haven't checked if ethernut does that, but I do that on
>>>>        
>> my
>>    
>>>> own code before calling ethernut functions.". Can you tell me the
>>>> functions for disabling/enabling interrupts? I found nothing in the
>>>>        
>> API.
>>    
>>>> So I can test if it works with disabled interrupts.
>>>>
>>>>
>>>>        
>>> NutEnterCritical and NutExitCritical disables and reenables
>>> interrupts, respectively. I've wrapped my code between those calls.
>>>
>>> Kind Regards,
>>>    Thiago A. Correa
>>> _______________________________________________
>>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>>
>>>
>>>      
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>    
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>  

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion