BUG in c51v808a.exe?
When i first connect the ULink the JTAG device ID is found and it is possible to program the device. After programming the device ID cannot been found anymore. Tried it with two units and both do not show up AFTER programming. The third (last) shows up all the time but i don't want to programm it because i don't know what happend.
Programmer: Keil ULink Device: ST upsd3434EV Software NOW: Keil uVision3 (eval c51v808a.exe) NOW Software Prev: Keil uVision3 eval uPSD (ST DK3400 kit)
Does the programmer blow op the device's JTAG interface. (uC is working afterwards, can't see if software is updated)
The hardware worked before because al three devices have been programmed and re-programmed various times. The only difference is: - I got a new PC and installed the newest Keil software to see if there are any changes since hte uPsd version.
NOW the question: Are there other people which have got the same problem?
Hmm, I'm still not sure if this couldn't be a matter of the changed revision... (Although I do not use C51V808.)
The PCN 1940 states: MCU JTAG ID changed to differentiate revision A from revision B silicon through the JTAG port. The PSD JTAG ID remains the same. Revision A MCU JTAG ID - 0x0451F041 Revision B MCU JTAG ID - 0x1451F041 [..] The impact will be to JTAG production programming equipment that may need to distinguish between revision A and B MCU silicon if the firmware is different depending on the revision level.
If I understand that correctly, as english is not my first tongue, the problem with the JTAG ID is firmware dependend, which then could very well be caused by the new KEIL software. What I mean to say is, that the problem might not be a generic issue from KEIL but that the change of the KEIL software just made this problem apparent!?
Maybe it's worth a try to change the settings of the JTAG Device Chain in the ULINK Driver Dialog (if you use uVision) from Automatic Detection to Manual Configuration and try out the different ID codes of the MCU revisions A and B.
Carsten
I haven't looked at your chip, but many processors have a configuration bit to turn off the JTAG interface, in a similar way that they may write-protect the flash, hard-code oscillator/oscillator frequency etc. Does your chip have any other erase method, such as a built-in serial-port monitor or a high-voltage erase pin or similar?
Partly solved. I took a RLINK programmer + CAPS software and all the devices could be Erased/Verified/Programmed again so nothing was wrong. I again connected the unit to de ULINK programmer and it could only see the empty devices.
Continued testing and it turns out the ULINK doesn't show the devices if the security bit has been set!
The uVision3 menu options flash->program and flash->erase both don't work because no device is detected (when the security bit has been set).
It seems the detection of locked devices has been changed in the newest software version (BUG?) because in the past the unit would mention the security bit and do a full chip erase. Very strange that the flash->erase also doesn't detect the devices. This means that i always need a second programmer (RLINK) to erase the devices. I could install the old Keil software again but that can't be the solution, i think i just will have to fill in a possible bug report.
So my guesses were obviously wrong.
Anyway, if you contact the KEIL support it would be nice if you could publish their answer here.
Maybe one day I will (have to) update to v808 too...?
Made a bug report and will keep you informed and post their reaction below. Bug report: Using ST DK3400 development board. Evaluating both Raisonance and Keil software.
Newest Keil uVision3 (eval c51v808a.exe) with ULINK doesn't reconize uPSD3434EV when lock bit has been set. (RLINK does reconize and can erase)
I have discussed the problem here on your forum.
http://www.keil.com/forum/docs/thread10258.asp
This problem is fixed now. Please see: http://www.keil.com/support/docs/3355.htm for more details.
Hans
As you can see above the bug was found and fixed. The updated ULINK driver indeed fixes the problem and now it works as it should (and worked in the past).