USBDM has been updated to V4.10.5
Please post any queries on this version in a separate thread - I really can't cope with this newfangled setup!
Documentation available at: SourceForge
Applications available at: SourceForge
Source code is available at: GitHub eventually.
USBDM V4.10.5 (May 2013)
Updated drivers for Windows
Only update the drivers if there have been problems (WinXP mostly). There is no added functionality
It is necessary to uninstall any existing driver installation using the Add or Remove Programs in the Control Panel.
Firstly - Please don't post questions on the end of an unrelated thread.
Please see this discussion which I believe represents the situation.
Other discussions can be found by searching for openSDA.
I have installed the version 4.10.5b on a new machine with win 7 64. In CFFlasher if I select usbdm-cff under BDM Communication I get the error: "Error loading protocol". What could be the reason for this?
Thank you very much.
I have now tested all versions 4.10.x and only with 4.10.4 and 4.10.5 CFFlasher showes this error. With 4.10.3 I can program a mcf5475 board, but the verify command causes errors even though the "memory window" in this area looks OK. Then I have tested it with a mcf54418 board, but I get no connection. The message is: "Error: BDM Established, but cannot write D0".
I hope, this helps.
Thank you for your message.
I have tried many versions of USBDM, and only usbdm-cff.dll from version 4.10.3(or earlier) works on MCF5274 and 28F128J3D. all never usbdm-cff.dll - send few data via USB, and CFFlasher - dead.
but in my case, with 4.10.3, the problem steel remains ((
in the read dump there are a lot of 0x80008000, and each time in a new place.
I changed the USB cable and port, laptop, windows XP_32 and 7_64, USBDM_CF firmware and many drivers.
nothing helped ((
In USBTrace and the file dump - often many 0x80008000 Dword,
i compare with original FW, no other error bits, just 0x80008000.
I don't know what the problem might be
- in the processor settings in CFFlasher, (i use setting from M5275EVB with my FLASHBASE)
wcreg RAMBAR1 RAMBAR1 0x1
write.l IPSBAR 0x00000000 IPSBAR 0x1
write.w IPSBAR 0x00000080 FLASHBASE>>0x10 0x00000000
write.w IPSBAR 0x0000008A 0x3D80
write.l IPSBAR 0x00000084 0x001F0001
write.w IPSBAR 0x00140000 0x0000
write.l IPSBAR 0x120000 0x01000000
- in the CFFlasher read algorithm, file 28F128J3D (1x8).alg / 28F128J3D (1x16).alg
no any code in USBTrace for read flash.
- or in bad USBDM_CF v3.1 board, I bought from taobao (seller nickname Alice).
if you have any thoughts regarding 0x80008000 in read dump, maybe this will help me.
thanks in advance.
I compare two USBTrase.
When i see Memory in CFFlasher, i get TWO 0x80008000 for 65536 bytes of read flash
When i upload 65536 bytes of flash dump in CFFlasher, i get 1641 DWord with 0x80008000.
it can be seen that memory reading is slower, so there are also fewer errors.
Please anybody tell me if there is a possibility to adjust the speed in usbdm-cff.dll from version 4.10.3.
or other way, for dump my flash in USBDM.
I saw a scripting interface there. I'll try to figure it out.
I found an error in the build process for the later version of usbdm_cff.dll that produces a DLL that won't load. This applies to 4.10.5 at least and probably some earlier versions as you have discovered.
Unfortunately I'm not getting very far with testing the solution to this as it the fixed version loads but when accessing the target it hangs somewhere in CFFlasher.exe on Windows 7.
I'll have to try an a Win-XP machine tomorrow. I also only have a couple of CFV2 chips to test with.
From the problems you are describing I suspect that the communication is unreliable. I'm unsure why.
There has been shuffling between machines that has caused this. There are no significant changes in the firmware so I won't fix it until I find another problem
Hello PGO, I've just installed v4.10.5a and I had this problem that was not present in v4.10.5:
This happens just with all the standalone programmers, all the other exe files run correctly. I'm running them in Windows 7 64-bit
Version 4.10.5a installs correctly, without any file corruption or something, considering that the installer grew 12 MB, from 41 MB in v4.10.5 to 53 MB in v4.10.5a, I think this is more like a a corrupted new library or something like that, I'm just guessing.
Unfortunately I moved machines (XP-32bit=>W7-64bit) between 4.10.5 and 4.10.5a - In theory they are little changed but the compiler seems to produce different code (different version of compiler amongst other things). All works fine on my new machine :smileyhappy:.
I'll do a build on the old machine and upload it until I can find out what the problem is.
Expect 4.10.5b real soon now!