Looking for any clues on how to resolve this.
I am using ec2drv (svn327) on FC7 with sdcc tool chain on a F340DK with EC3 (firmware 0x0d)
Flashing new apps into my F340DK worked fine for the last couple of days (including this morning) and then something broke.
ec2writeflash --port=USB --mode=C2 --hex f340_app.ihx
ec2writeflash:ec2drv.c:1933:
usb_interrupt_read in read_usb returned -110: Connection timed out
After un/replug the ec3 adapter I can run ec2device and it reports properly.
I can read out the flash OK too. but any ec2write flash errors.
I tried ec3-fw-0x0c, but same problem.
I verified under win$ and everything works fine. No problem downloading and running
new programs using the silab IDE.
any ideas?
mattes
PS before it 'broke' I was sucessfully downloading and running a ported version of
silabs test examples T2Cal33x. though I did this 2-3 times until ec2writeflash bailed on me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm not sure what the problem is,
It could be that the device has had its lock bytes written and needs a full erase to write. perhaps try the --eraseall option in ec2writeflash although I would have thought windows would have needed to erase them too. By default ec2writeflash only erases the pages it is about to write to so dosen't reset any locks.
I think if the comms gets messed up due to a locked device you might get that USB error, Its been a while since I accidentally locked a device.
I'll look over the code later tonight to see if I can spot anything else.
Ricky
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I finally got to the source of the problem. The program (t2cal33x) I initially downloaded attempts to modify some data in the flash code itself. The function doing so was broken (actually not suited for the f340). Application Note 201 finally shed some light on it and i was able to fix it.
The broken code actually messed something up inside the F340. Running it in the debugger i noticed it never went past the flash write code. instead it restarts the code from the beginning. The F340 manual states that in case of error on flash writes the device needs to be reset. (Not sure what that means exactly).
I know though that 'ec2writeflash' times out, when trying to burn a new program.
Is it possible the flash API requires a RESET to be activated, to get the f340 back in line?
It seems like the IDE (win$) must doing something like this. No problem to re-program it, after running the broken code (see above).
Ricky, you seem to be the master of the ec2writeflash. Ever run across something that allows to reset the device, via the USB EC3 programmer API. If there is such thing, it could be easily added to ec2writeflash before writing a new program to flash.
(I looked at the usbsnoop output. pretty intense data collection and it looks all 'greek' to me, "...too much input...")
mattes
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had this same problem. After uploading one of the examples, ec2drv can no longer write to the MCU but the SILabs IDE has no problem. It seems like the firmware in the EC3 is getting corrupted when it uploads certain images. Unfortunately, the firmware updater that came with ec2drv doesn't work for me. It just exits without even looking for the EC3. I think the image parameter is no longer used, but using the block parameter with the .raw files from the site causes a seg fault.
Here's what I did to fix the problem.
Go to the utilities directory in the SILabs IDE installation. There is a program called USB Reset there. Use it to update the firmware in the EC3. Then go to the IDE and connect to the EC3. It should say that the firmware needs to be updated. Let it update. Now the EC3 should be working again with ec2drv.
My firmware is version 0x10, and as I said I cannot update it with a supported version. I'm not sure that this process is even changing the firmware, because it reports the same version at every step. It may just be resetting the device in some way.
If anyone is interested in fixing this, I can send the example program and image that cause the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I figured part of it out. Whenever the missing clock detector is enabled in the MCU, the write error occurs. On the 8051F340 this is enabled by setting RSTSRC = 0x04. Commenting out this line fixed the problem. The spec for this MCU notes that this feature needs to be turned off before the device can be reprogrammed, so I think ec2drv needs to clear this bit before it tries to write anything to the chip.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
Makes sense, we mess with rstsrc for the F53x family specifically disable missing clock detector.
I can look at adding this for the F340 but I currently don't have a working F340 board to test on.
Thanks for the info
Ricky
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looking for any clues on how to resolve this.
I am using ec2drv (svn327) on FC7 with sdcc tool chain on a F340DK with EC3 (firmware 0x0d)
Flashing new apps into my F340DK worked fine for the last couple of days (including this morning) and then something broke.
ec2writeflash --port=USB --mode=C2 --hex f340_app.ihx
ec2writeflash:ec2drv.c:1933:
usb_interrupt_read in read_usb returned -110: Connection timed out
After un/replug the ec3 adapter I can run ec2device and it reports properly.
I can read out the flash OK too. but any ec2write flash errors.
I tried ec3-fw-0x0c, but same problem.
I verified under win$ and everything works fine. No problem downloading and running
new programs using the silab IDE.
any ideas?
mattes
PS before it 'broke' I was sucessfully downloading and running a ported version of
silabs test examples T2Cal33x. though I did this 2-3 times until ec2writeflash bailed on me.
Hi,
I'm not sure what the problem is,
It could be that the device has had its lock bytes written and needs a full erase to write. perhaps try the --eraseall option in ec2writeflash although I would have thought windows would have needed to erase them too. By default ec2writeflash only erases the pages it is about to write to so dosen't reset any locks.
I think if the comms gets messed up due to a locked device you might get that USB error, Its been a while since I accidentally locked a device.
I'll look over the code later tonight to see if I can spot anything else.
Ricky
I finally got to the source of the problem. The program (t2cal33x) I initially downloaded attempts to modify some data in the flash code itself. The function doing so was broken (actually not suited for the f340). Application Note 201 finally shed some light on it and i was able to fix it.
The broken code actually messed something up inside the F340. Running it in the debugger i noticed it never went past the flash write code. instead it restarts the code from the beginning. The F340 manual states that in case of error on flash writes the device needs to be reset. (Not sure what that means exactly).
I know though that 'ec2writeflash' times out, when trying to burn a new program.
Is it possible the flash API requires a RESET to be activated, to get the f340 back in line?
It seems like the IDE (win$) must doing something like this. No problem to re-program it, after running the broken code (see above).
Ricky, you seem to be the master of the ec2writeflash. Ever run across something that allows to reset the device, via the USB EC3 programmer API. If there is such thing, it could be easily added to ec2writeflash before writing a new program to flash.
(I looked at the usbsnoop output. pretty intense data collection and it looks all 'greek' to me, "...too much input...")
mattes
I had this same problem. After uploading one of the examples, ec2drv can no longer write to the MCU but the SILabs IDE has no problem. It seems like the firmware in the EC3 is getting corrupted when it uploads certain images. Unfortunately, the firmware updater that came with ec2drv doesn't work for me. It just exits without even looking for the EC3. I think the image parameter is no longer used, but using the block parameter with the .raw files from the site causes a seg fault.
Here's what I did to fix the problem.
Go to the utilities directory in the SILabs IDE installation. There is a program called USB Reset there. Use it to update the firmware in the EC3. Then go to the IDE and connect to the EC3. It should say that the firmware needs to be updated. Let it update. Now the EC3 should be working again with ec2drv.
My firmware is version 0x10, and as I said I cannot update it with a supported version. I'm not sure that this process is even changing the firmware, because it reports the same version at every step. It may just be resetting the device in some way.
If anyone is interested in fixing this, I can send the example program and image that cause the problem.
I think I figured part of it out. Whenever the missing clock detector is enabled in the MCU, the write error occurs. On the 8051F340 this is enabled by setting RSTSRC = 0x04. Commenting out this line fixed the problem. The spec for this MCU notes that this feature needs to be turned off before the device can be reprogrammed, so I think ec2drv needs to clear this bit before it tries to write anything to the chip.
Hi
Makes sense, we mess with rstsrc for the F53x family specifically disable missing clock detector.
I can look at adding this for the F340 but I currently don't have a working F340 board to test on.
Thanks for the info
Ricky