• Seems like hotmail /outlook is blocking emails from here so please refrain from using one of these accounts as you may not receive your authorization email.. many thanks

AT26DF161A Odd Behavior

BenLevine

New Member
I was successfully able to use the program with the 16pin chip clip on a W25Q64JVFIQ device, so I can verify that the program and FlashcatUSB Pro are working correctly. Now I have changed to the 4 pin chip clip to program an Atmel AT26DF161A chip and I am seeing the following odd behavior.
1) While trying to program the device it was failing on writing the first sector. I could tell the program was retrying 2 more times after failing, but then it would just say it failed to write and ask if I wanted to continue.
2) Then I used my old emulator setup through JTAG on the device to write the program back onto the flash memory chip and I found the following odd behavior which might be the reason I am having the problem. When I first connect to the device and it reads the first bit of memory I get the following contents which look correct as far as I can tell. However as soon as I press the down arrow to move down one line the contents of the box change significantly, with some bytes changing completely and some look like the hex characters are just swapping.

I have enclosed the screen shot of the status screen showing connection to the device and one image showing the contents starting at 0x00, and the next image showing what happens when I press the down arrow and presumably the contents are refreshing with an offset of 0x10. Perhaps this can explain the programming errors as well.
I did verify with the W25Q64JVFIQ device that I can press the down button to view data at an offset and the contents stay as they should be instead of changing like with the AT26DF151A.

Any insight is appreciated! Thanks,
- Ben
 

Attachments

BenLevine

New Member
After experimenting a bit more and comparing what is read to the actual data, it appears that depending on the offset I read at I am getting some bit shifting. Not sure what explains that or how to fix that, but you can make sense of some of the data by shifting the bits in the expected data.
 

BenLevine

New Member
I just verified the chip clip hardware by connecting to an AT25DF321 chip and it does not exhibit the same behavior when reading from different offsets

*EDIT* This is an 8 pin chip clip, I referred to it as a 4 pin chip clip in the original post
 
Last edited:

Pantheon

Active Member
Developer
Sometimes when there are issues, I check the IC in a socket. If it has no problem there, then its the board that is the problem.
 

BenLevine

New Member
Thank you for the suggestion Pantheon. before I removed the chip I powered the board separately and halted the processor and then I was able to read the chip properly. I will try programming the chip in the same manner today. I'm guessing that either the programmer was providing enough power for the processor to run and other items on the SPI were also being selected by the processor, or the power was being dragged down by other components on the board and couldn't read properly. Either way powering the board separately and halting the processor allowed me to read everything consistently. Thanks again!
 
Top