Arm Community
Site
Search
User
Site
Search
User
Groups
Arm Research
DesignStart
Education Hub
Graphics and Gaming
High Performance Computing
Innovation
Multimedia
Open Source Software and Platforms
Physical
Processors
Security
System
Software Tools
TrustZone for Armv8-M
中文社区
Blog
Announcements
Artificial Intelligence
Automotive
Healthcare
HPC
Infrastructure
Innovation
Internet of Things
Machine Learning
Mobile
Smart Homes
Wearables
Forums
All developer forums
IP Product forums
Tool & Software forums
Pelion IoT Platform
Support
Open a support case
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Developer Community
Tools and Software
Software Tools
Jump...
Cancel
Software Tools
Arm Development Studio forum
A mysterious problem with At91Sam7S256
Tools, Software and IDEs blog
Forums
Videos & Files
Help
Jump...
Cancel
New
Replies
2 replies
Subscribers
127 subscribers
Views
1523 views
Users
0 members are here
Related
A mysterious problem with At91Sam7S256
Offline
David VanHorn
over 7 years ago
Note: This was originally posted on 4th October 2011 at http://forums.arm.com
This is likely to be highly vendor specific, but I am hoping someone can shed some light.
We are setting up the WDT to fire an internal and external reset.
The problem is that the chip hangs in a reset loop appx every 20mS. The WDT can be set for any timeout up to the 16 second max, and we get the same 20mS loop.
We thought that this was a bad PCB issue, PLL issue (even happens when the PLL is not used.) Crystal startup issue (problem also happens with other types of crystals, and oscillator startup looks good) VDD risetime issue (verified risetime significantly faster than required), bypassing issue (PCB runs fine with almost all bypass caps removed, adding more does not affect the problem)
Interestingly, the WDT values that are listed as "working" values for the rev A silicon seem to cause the problem to appear less often than other values.
https://www.ledato.de/download/SAM7S256_128_errata_%28update-13Nov%29.pdf
We have seen this problem with the window enabled or disabled, and we intend to run with the window disabled. If we are having a problem with a given board, we can cause the chip to boot up properly by either heating or cooling by a fraction of a degree, or by applying a slight torque/twist to the PCB. The direction of the force is important, but is not the same for two different boards. Once a given board has booted properly, it is extremely robust. They survive power line disturbances at 2.5kV with 10nS rise time, EMI at >190V/M, and ESD events at 16kV while operating.
While the mechanical sensitivity would seem to indicate a PCB problem, we have replicated this on an Atmel evaluation kit board. The amount of flex varies, as little as 1/16th inch over 8" of board length to take it into or out of failure. The thermal sensitivity is also extreme, heat from a slight touch of finger on the CPU for only a couple seconds is enough to induce or stop the rebooting. I can't imagine the die temperature is changing more than a fraction of a degree.
The problem shows up with rev A, B, and C silicon.
We implemented an extremely stripped down version of the code that only flashes some LEDs to indicate that the application is running, and this code also exhibits the problem.
The best that we have been able to do so far is to isolate that it seems to do with when (relative to rise of /RESET) the WDT is initted. For a given chip, if we change where in time the WDT is configured using NOPs, we can create or eliminate the problem on that board. Some chips don't seem to exhibit the problem but since temperature, timing, and PCB flex all seem to be part of the equation we are only comfortable saying that a given system "has not been observed to have the problem".
There may be some relationship with the phase or timing of the slow clock, at the time that the WDT is configured, but we have not been able to find anything yet.
Out of a couple hundred of our boards, roughly 10% exhibit the problem with a given code set. If we had three boards fall out from a batch "A", "B", and "C" then if we change the time before the WDT is initted and re-program the batch, maybe "A", "D", and "W" would fail. We have a codeset that has never been observed to fail, but given the nature of the problem, we are extremely nervous.
We have been through the errata and the data sheet extensively both by ourselves and at Atmel in San Jose, with their technical people. So far nobody can explain why we are seeing this.
Has anyone here seen this problem? Solved it?
Thanks.
Offline
Alban Rampon
over 7 years ago
Note: This was originally posted on 5th October 2011 at
http://forums.arm.com
Hello DVanhorn,
As this seems very Atmel and silicon revision specific, I think it might be more fruitful for you to ask a dedicated community:
AT91SAM Community - SAM7 board
Kind regards, Alban
Cancel
Up
0
Down
Reply
Cancel
Offline
David VanHorn
over 7 years ago
Note: This was originally posted on 5th October 2011 at
http://forums.arm.com
As I mentioned in the first line, this may be a vendor specific issue. I have posted it there too..
It seems to affect all three available revs of this part, and my concern is that the problem may be located in a section that atmel didn't design.
This is why I posted it here.
Cancel
Up
0
Down
Reply
Cancel
More questions in this forum
By title
By date
By reply count
By view count
By most asked
By votes
By quality
Descending
Ascending
All recent questions
Unread questions
Questions you've participated in
Questions you've asked
Unanswered questions
Answered questions
Questions with suggested answers
Questions with no replies
Suggested Answer
Positioning a function in a Position Independent Executable for ARMV8
0
5888
views
3
replies
Latest
1 month ago
by
Stephen Theobald
Answered
Link a pure binary file to image with scatter file
0
5845
views
3
replies
Latest
1 month ago
by
Ronan Synnott
Answered
Failed to read contents of Internal RAM L1-I_DATA in ARM DS
0
Arm Development Studio
Cache
Debug and Trace Services Layer (DTSL)
10093
views
23
replies
Latest
1 month ago
by
Boon Khai
Suggested Answer
DS-5 connect fail when cortex-r5 is in lock-step mode
0
8446
views
10
replies
Latest
2 months ago
by
Stuart Hirons
Suggested Answer
On Cortex-M4F microcontrollers: is fixed point math faster or floating point?
0
8114
views
10
replies
Latest
2 months ago
by
Ronan Synnott
<
>
View all questions in Arm Development Studio forum