ATMEL AT91FR40162 corrupted FW?

[Wiljan]

I help on finding a fault on a CNC machine using 3 x Motor drives S300 from Koolmorgen
One of the drives does make a fault while powering on. A power cycle or more maybe 5 makes it works)

This fault has only been there over the last 6 month and get more and more often (the CNC is from back 2006 or so)

So adding a serial 38.400 terminal on the faulty drive shows this

//------When it works--------
booting...
checking firmware integrity...ok !!!
starting firmware 2.00
Init Rs232
FPGA Initialisation done

-->

//------When it failing--------

booting...
checking firmware integrity...no firmware !
starting SRMON 0.66

SR-Monitor.  Danaher Motion
[SRMON Rev 0.66 Dec 14 10:53:51 2004]
FPGA Initialisation done
SRMON>

The MPU in the system is an Atmel AT91FR40162 there are also a few PFGA's  and a lot of interface's and sure some highvoltage drivers.

If I only run the 24V I get fine 5V and 3V3 and 1V8 I have found a reset line and if I pull that to ground the ATMEL does reboot and makes same as if 24 its powercycled.

So it clear that the bootloader does load and it the properly calculate some CRC for the Program memory (FW) which fial more and more.

So here comes the question:
Is it normal that an old ATMEL does get shaky bit in the Flash Program memory?
Will a erase and new download of FW make a stable program memory?
Why is becomming worse and worse?

I recall with old EPROM 27xx with a small window the sunlight (UV) could make the bit's to be week / erased is this the same kind of problem in an ATMEL?

I really wanted to be sure a reflash FW will make a difference, problem is there are only newer FW and there more than 300 parameters save in the drive which must not be lost so it's always risky to flash FW in such devices.

Should I expect it's a faulty Atmel and only cure is to replace it (BGA121)?

Hope it makes sense

[abyrvalg]

Flash cells could leak the charge with time and get unstable. Try reading the full flash out several times, then take a binary AND of all dumps (leaked cells shits towards 1 state). How to read? - this chip has a JTAG debug port, look for some pin headers inside. Also that SRMON> prompt looks like some debug monitor console, perhaps it has some memory read functionality (try typing “help” there).

[Wiljan]

Flash cells could leak the charge with time and get unstable. Try reading the full flash out several times, then take a binary AND of all dumps (leaked cells shits towards 1 state). How to read? - this chip has a JTAG debug port, look for some pin headers inside. Also that SRMON> prompt looks like some debug monitor console, perhaps it has some memory read functionality (try typing “help” there).

Thx, there is a 10 pin header next to the Atmel might be a JTAG but hard to check when it's a BGA chip.

regarding the SRMON I have those options:

booting...
checking firmware integrity...no firmware !
starting SRMON 0.66

SR-Monitor.  Danaher Motion
[SRMON Rev 0.66 Dec 14 10:53:51 2004]
SRMON> ?
Register
   <register name> [<data>]    - Set register
   R                           - Display Registers
Memory
   A       <start adr>         - Assemble
   C       <range> <dest adr>  - Copy memory
   CLR                         - clear serial eeprom
   CX/CUPDATE                  - Load Program into flash (CAN)
   D<type> <range>             - Display memory
   DA/DI   <start addr>        - Disassemble
   F<type> <range> <data>      - Fill Memory
   M<type> <start adr>         - Modify memory
   IO      <value>             - Write to Output Port
Running
   B  <adr> [<count>]          - Set PC breakpoints
   B                           - Display breakpoints
   B  - [<adr>]                - Cancel breakpoints
   G  [<start adr>]            - Go
   S  [<count> [<start adr>]]  - Single Step
   SO                          - Step over
[space to continue help]
SRMON>

Any suggestions how to dump to serial?

[abyrvalg]

Try guessing the D command format, i.e. DB 0-100, or DB 0:100, not sure what does it want for <range>, what separator is used. The boot flash memory starts at addr 0 and ends at 200000. To save the dump output into a file you can use PuTTY serial terminal with file logging enabled and get the dump from that log file.

[Wiljan]

Try guessing the D command format, i.e. DB 0-100, or DB 0:100, not sure what does it want for <range>, what separator is used. The boot flash memory starts at addr 0 and ends at 200000. To save the dump output into a file you can use PuTTY serial terminal with file logging enabled and get the dump from that log file.

Yes the "DB 0 200000" does work and yes I can save it to an file.

Code: [Select]

DB 0 100000
00000000  18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5   ................
00000010  18 F0 9F E5 00 00 A0 E1 20 FF 1F E5 20 FF 1F E5   ........ ... ...
00000020  84 C0 00 01 88 C0 00 01 8C C0 00 01 90 C0 00 01   ................
00000030  94 C0 00 01 A8 8C DF 67 3A 2E E7 00 8A 36 70 34   .......g:....6p4
00000040  00 96 00 00 01 00 00 00 0A 00 00 00 00 00 00 00   ................
00000050  4C 42 01 01 54 42 01 01 58 42 01 01 5C 42 01 01   LB..TB..XB..\B..
00000060  60 42 01 01 64 42 01 01 68 42 01 01 D0 42 01 01   `B..dB..hB...B..
00000070  D4 42 01 01 D8 42 01 01 DC 42 01 01 E0 42 01 01   .B...B...B...B..
00000080  E4 42 01 01 E8 42 01 01 EC 42 01 01 F0 42 01 01   .B...B...B...B..
00000090  F4 42 01 01 F8 42 01 01 FC 42 01 01 00 43 01 01   .B...B...B...C..
000000A0  04 43 01 01 08 43 01 01 0C 43 01 01 10 43 01 01   .C...C...C...C..
000000B0  14 43 01 01 18 43 01 01 1C 43 01 01 20 43 01 01   .C...C...C.. C..

But this really does not help on the problem since it's only the 200K RAM which are dumped and the FW which are 2M.
Also I done see how this would fix the "faulty" bits.

I could see the parameter in the RAM dump and the were equal to the official exported values so I believe this it good.

I have now flashed a newer FW to the board took 45 minutes even the serial did switched to 115.200 and now it boots correct on every power cycle. (did test 25 times) 

Next week I will put it back to the CND and see it it works correctly and if the parameters actually was kept correct.

The mechanical guy did tell that the best test on a CNC is to cut circle this will show exactly if like speed, acceleration ramps, gear ratio  etc are spot on.

Then time will show it the problem does come back.


 

[abyrvalg]

So:
- the numbers are decimals by default
- the flash seems to be remapped to 0x01000000 (all vectors point into that area)

try DB 0x01000000 0x200000 - this should dump full flash