Chameleon memory problem

[Peterthegreat]

Hello, So this is a pretty annoying issue. The memory of the IC somehow gets corrupted (mostly if you power it off during startup). The ChameleonMini is not responding - the LEDs power off and not seen on USB. To reproduce the problem, (optional? load some data to be emulated) toggle the power switch fast a couple of times.

I am uploading the boot-loader with an USBASP, using this config for the IC:

part parent ".xmega" id = "x128a4u"; desc = "ATxmega128A4U"; signature = 0x1e 0x97 0x46; // usbpid = 0x2fde;

memory "eeprom"
    size        = 0x800;
    offset      = 0x8c0000;
    page_size   = 0x20;
    readsize    = 0x100;
;

memory "application"
    size        = 0x20000;
    offset      = 0x800000;
    page_size   = 0x100;
    readsize    = 0x100;
;

memory "apptable"
    size        = 0x1000;
    offset      = 0x81f000;
    page_size   = 0x100;
    readsize    = 0x100;
;

memory "boot"
    size        = 0x00002000;
    offset      = 0x00820000;
    page_size   = 0x100;
    readsize    = 0x100;
;

memory "flash"
    size        = 0x22000;
    offset      = 0x800000;
    page_size   = 0x100;
    readsize    = 0x100;
;

memory "usersig"
    size        = 0x100;
    offset      = 0x8e0400;
    page_size   = 0x100;
    readsize    = 0x100;
;

; ` Then I upload the code via USB with "ChameleonFirmwareUpgrade.bat"

I don't know sure if the problem is in the flash, in the EEPROM or somewhere else, but one time while having this issue the Chameleon got into boot-loader mode and I was able to rewrite the memory. First I uploaded only the EEPROM.

"%~dp0dfu-programmer.exe" atxmega128a4u flash-eeprom "%~dp0Chameleon-Mini.eep" --force
"%~dp0dfu-programmer.exe" atxmega128a4u launch

This did not made any difference, the LEDs where still off, and the Chameleon was still in boot-loader mode. Then I uploaded only the flash, and the result was the same.

To make it work, I have to erase the IC and rewrite the boot-loader and the flash+EEPROM

Things that I have tried:

• different firmware "ChameleonMini RevG 161024 using LDFA 151115 compiled with AVR-GCC 4.9.2" (but the same boot-loader version bootloader-atxmega128a4u-104-PA6-SPM)
• replace C1 and C2 with higher values (10u)
• replace the IC with a new one

Attached are the eeprom and flash of the IC when this issue happens

dead-FLASH.hex.txt dead-EEPROM.eep.txt

My guess is that my power on switch has imperfect contacts and sometimes an on-off toggle is happening while powering on the ChameleonMini. I will replace the switch but it doesn't guarantee that it won't happen again.

[Peterthegreat]

Also, when this happens, there is no 13.56mhz signal on the oscilator

[Peterthegreat]

The problem appeared again, this time after using chamlog.py. First the chamlog did not respond, so i did a restart. Then the PC could not see the Chameleon on USB. After another restart, the device was in bootloader mode. I took the chance and uploaded the EEPROM, without erasing the chip first.

This made the device disappear from USB, but after pressing RBTN, it was back to bootloader mode.

Then I uploaded the .hex, again without an initial erase:

And then with --force argument:

And the device was seen via USB and appears to be working. I will now reproduce the problem and will try to upload the flash memory first (.hex)

Bonus img, an erase when the problem is present (I am aware that in this case, is just an erase and the eeprom uploaded, so the cameleon won't work):

[Peterthegreat]

Ok, so that writing without erasing the chip did not lasted long. While trying to reproduce the problem with the on/off toggle, the device was not recognize anymore (VID&PID)

After a few more attempts, the correct com was shown and this is what the gui shows

After resetting the comunication, the device is unrecognized again. (USB\VID_0000&PID_0002\5&1FE61B32&0&2)

[geo-rg]

Sorry for the late reply. We really could not reproduce your problem. Have you tried to replace your power switch? However, I cannot imagine how a bad contact on the power switch would cause memory corruptions within the flash memory. Have you gained any new information on your problem?

[Peterthegreat]

No worries. Do you think that my method of programming the IC is ok? I am using a patched fw for my USBASP that allows me to write to Xmega cips, but I am using it only to upload the bootloader, and avrdude verificiation step shows that is done correctly. The UpdateFirmware.bat uses USB and also has an erase command before writing the flash.

[Peterthegreat]

I did not changed the power switch yet (but the problem seems to be at power up). Meanwhile, I will try my best to find exactly when this is happening, so you can reproduce the problem. Thank you for the support

[Peterthegreat]

Just changed the power switch and I still get the random "death" of the board. Since I am the only one having this problem, I will recheck the values from the BoM

[skuep]

Can you give the microcontrollers fuse settings? Maybe the brown out detector is not correctly configured.

[Peterthegreat]

avrdude -v option doesn't show the fuse bits, I will have to get them some other way. I did not changed the default fuse settings

"lfuse" memory type not defined for part "ATxmega128A4U". Let me update avrdude's config

[Peterthegreat]

@skuep I am not sure this is correct, but here is my attempt: fuse0: 0xff fuse1: 0x0 fuse2: 0xff fuse4: 0xfe fuse5: 0xff

Anyway, I think that the brown out detector should not remain stuck or affect any part of the IC's memory.

[Peterthegreat]

Rechecked the BoM and everything looks fine (I have an equivalent for D5). Did a reflow on the left part of the board, but the problem is still there. Next step I will try a bigger value for C8 and C9 (input and output of the 3.3 voltage regulator)

[geo-rg]

@Peterthegreat The Fuses you have set are not correct. Just try these: fuse1: 0x00 fuse2: 0xBE fuse4: 0xF3 fuse5: 0xED

[Peterthegreat]

I would gladly try those fuse settings, but first, can you please confirm I got the memory address right? Here is my avrdude config:

` memory "fuse0" size = 1; offset = 0x8f0020; ;

memory "fuse1"
    size        = 1;
    offset      = 0x8f0021;
;

memory "fuse2"
    size        = 1;
    offset      = 0x8f0022;
;

memory "fuse4"
    size        = 1;
    offset      = 0x8f0024;
;

memory "fuse5"
    size        = 1;
    offset      = 0x8f0025;
;`

Edit: I assume that fuse0 is correct since you did not mention it. I forgot about fuse6. Is it important?

memory "fuse6" size = 1; offset = 0x8f0026; ;

[Peterthegreat]

Forgot to post an update. Changed Q1 and got bigger values for C8 and C9, but did not solved anything, except a slightly better read from my phone's NFC . Now I uploaded the fuse bit configuration. Will post the results

[Peterthegreat]

That was it! No idea how the fuse bits got changed.. Maybe they were wrong form the start. I got the problem a long time ago, but only recent had time to play more intensively with the chameleon.

Thank you guys, now I can focus on closing the other issues.