[En-Nut-Discussion] Non reproduceable reboots on 1.3H
ziu82 at gmx.de
Mon Aug 31 13:24:07 CEST 2009
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?
> 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,
More information about the En-Nut-Discussion