STR912 Ghosts and Odd Behavior

[steve12]

Posted on October 02, 2007 at 12:36

STR912 Ghosts and Odd Behavior

[steve12]

Posted on May 17, 2011 at 09:47

Hello,

We have been tracking a number of very very very odd behaviors in the STR912FA Rev G series. In particular, we have a situation now where it looks like we run for several hours and then large sections of the internal ram are overwritten with 0's - corrupting sturctures and causing a lockup. I do not see any stack overflows after inspecting the corruption. We also see very strage behavior with the optimization levels. By altering optimization, sometimes we can make our code stop working. Usually, the less optimizaton - the more likely it is to break. But this still varies from compile-to-compile. We are using IAR 4.41A, STR912FA revG, FreeRTOS and uIP. One of the internal ram faults that occurs is the uip_conns structure (which holds the TCP ports that our application is listening to) is reset to all 0's - so we loose all network access to the processor. Has anyone seen anything like this? Thanks

[mark9]

Posted on May 17, 2011 at 09:47

Many years of programming suggests to me a software bug before a hardware bug.

However, I *have* had a case where the optimizer sudden caused my code to lock the CPU, and now ST Micro has verified that this is a real issue. In this case, the optimizer had scheduled the load instructions to maximize use of the pipeline, during a read of the ADC data register. In this case (sometimes), it would lock the CPU. If the instructions were reordered to be less efficient, it would not lock. However, this is not related to memory being filled with zeros. This is probably a software issue, but you might also want to take a look at your power supply.

[steve12]

Posted on May 17, 2011 at 09:47

Hi,

the issue appears to be related to the uIP stack. I thought we had it working, but we are back to the same ghost-issues with the STR912. The uIP stack becomes progressively worse after recompiling several times. And now, we have it in a way where we can use DHCP to get an IPaddress, but then we cannot ping/etc because the uIP's address buffer no longer contains the IP we just got via DHCP. After debugging for a bit, now we cannot even send DHCP to get an IP address. We have been here a week or so ago - and now we are back in the same boat. Also, seems that setting optimization to NONE completely breaks uIP in the STR912. Something is not right with this chip and/or toolchain.

[steve12]

Posted on May 17, 2011 at 09:47

Also - I have seen on this forum that folks may be ported FreeRTOS to use the GCC compiler.

Is there a guide on how to do this? I would like to try a new compiler environment to target the STR912. I am using a set of internal code for file system access and command parsing, then we have the FreeRTOS kernel, I have ported libmad into IAR - so this should be buildable under a straight GCC tool. Thanks

[steve12]

Posted on May 17, 2011 at 09:47

More details on this:

It appears that there is either some kind of instruction sequence and/or memory mapping problem here. I believe memory mapping to be the issue. First, I have a ''working'' set of code that allows uIP access (DHCP and TCP), I have a command parser, and an implementation of libmad to allow MP3 playback using the STR912. Now, i add ONE MORE int variable. And I reboot - DHCP works, however, I can no longer connect via TCP - the unit sees packets, but does not respond. Remove the new int variable - and TCP comes back. The new int variable is a startup delay in the interrupt service routine that transfers data to the external DAC. The variable startdelay is declared as int startdelay. This requires 4 more bytes of internal memory - somehome, breaking the uIP stack. Now, I change the declarion of the variable to __no_init int startdelay. My __no_init is declared via the linker script to live in external RAM. Now my uIP stack works again. So it seems, perhaps with IAR 4.41, maybe some sections of code are not always updated when the ram area changes??? Thoughts?