USBDM with CodeSourcery GCC/GDB?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USBDM with CodeSourcery GCC/GDB?

Jump to solution
5,371 Views
thm59
Contributor II

The free (lite) version of the CodeSourcery  GNU (GCC/GDB)  toolchain for ColdFire (m68k-elf-gcc) doesn’t include a tool for flashing the µC (which is present in the commercial - some hundred USD- version of the toolchain) .

PGO kindly proposes a nice programmer for CFV1, but the USBDM is not recognized by the GDB server (m68k-elf-sprite) of the toolchain  although  the Freescale OSBDM-JM60 is supported.

Does anybody succeeded in adapting the USBDM dll for the codesourcery m68k-elf-sprite  ?
It would be nice in the sense that it would result to a fully unlimited free toolchain for CFV1 (working fine with Eclipse).

 

Thierry

Tags (2)
0 Kudos
1 Solution
2,523 Views
pgo
Senior Contributor V

Dear Thierry,

 

The appearance of two targets is expected.  This is the method used to determine if the BDM is to look for a CFV1 or CFVx target.  See the Readme file with the DLLs.

 

I've fixed the problem with RAM targets I believe - See the Late updates on version 4.5.

 

The V4.5 online documentation also now has a HOW-TO for the method used with a RAM target and Codesourcery.

 

CFFlasher is now also supported.

 

bye

View solution in original post

0 Kudos
20 Replies
2,522 Views
pgo
Senior Contributor V

Dear Thierry,

 

If you are using Windows and are feeling brave you can try the file:

 

http://sourceforge.net/projects/usbdm/files/Version%204.4/Late%20Updates/CodeSourceryHack.zip/downlo...

 

This is a DLL that makes the USBDM look like a OSBDM-JM60 with a CFV1 target (at least as far as CodeSourcery thinks).

Place the DLL in the same directory as the sprite so it is found instead of the genuine item.

 

I have used it with CodeSourcery lite and Eclipse under Win-XP to do some simple tests with a MCF51CN128.

 

You have to flash the chip beforehand using the stand-alone programmer.  The programmer only supports S19 files so you have to generate them.  I believe m68k-elf-objcopy.exe can be used for this but I actually used the  -Wl,--oformat,srec option to the linker.  You still need the usual format output (elf?) for the debugger symbols.

 

It is rather fragile because CodeSourcery doesn't trigger resyncs as often as Codewarrior.

Codewarrior is a significantly easier beast to use.

 

bye

0 Kudos
2,523 Views
thm59
Contributor II

Thank you very much, Pgo

 

It is easy to generate S19 file form elf with m68k-elf-objcopy, and i can configurate the CFV1 flasher as "external tool" of Eclipse, which is relatively easy to use.

I have made frist trials with my demoqe128, the flash programmer works fine, but for the moment,  the m68K-elf-sprite find not the usbdm by changing the osbdm-jm60 dll (and adding the appropritate usbdm dll's)

I will make more tests from a "clean" configuration and read carefully the documentation.

 

Best regards,

 

Thierry

 

PS: I have the minimal JS16 usbdm with V4.3 firmware

0 Kudos
2,523 Views
pgo
Senior Contributor V

Sorry the instructions are rather incomplete!

 

Copy the following to the C:\Program Files\CodeSourcery\Sourcery G++ Lite\bin directory:

osbdm-jm60.dll

libusb-1.0.dll

I renamed the osbdm-jm60.dll DLL in the windows directories to make sure it didn't get used but I don't think this is necessary.  I've updated the file on SourceForge to include the other DLL.

 

You can do a very basic test of the sprite using the command:

m68k-elf-sprite  osbdm:0

It should complain about a missing config file and indicate that the target is reset.

 

I used the following in the debugger launch startup tab

target remote | m68k-elf-sprite osbdm:0 mcf51cn128
load

 

This was with V4.4 firmware but it should work OK with 4.3 (I think).

 

Note: This is a debug version so it's slow and there are copious log messages in the %APPDATA%/usbdm/usbdm.log file.

 

bye

 

 

 

 

 

0 Kudos
2,523 Views
thm59
Contributor II

Hello, PGO

 

Many thanks

 

The dll is woking fine with the  previous 4.4-215 (spring 2010) version . With the command m68k-elf-sprite -i , I get:

 

CodeSourcery ColdFire Debug Sprite (Sourcery G++ Lite 4.4-215)
pe: [speed=<n:0-31>&memory-timeout=<n:0-99>] P&E Adaptor
ccs: [timeout=<n>&speed=<n>] CCS Protocol
  ccs://$Host:$Port/$Chain_position - Command Converter Server
tblcf: TBLCF Interface
osbdm: Open Source BDM
  osbdm://0/ - OSBDM device

I can program, debug without problem, .. .The main advantage of Codesourcery lite is that it is unlimited (64K for CW).

 

Unfortunatley, withe the latest (sept 2010)  version of the Sourcery suite, the usbdm is not found,  :

 

CodeSourcery ColdFire Debug Sprite (Sourcery G++ Lite 2010.09-39)
pe: [speed=<n:0-31>&memory-timeout=<n:0-99>] P&E Adaptor
ccs: [timeout=<n>&speed=<n>] CCS Protocol
  ccs://$Host:$Port/$Chain_position - Command Converter Server
tblcf: TBLCF Interface
osbdm: Open Source BDM

 

and I have no idea for further test.

 

Regards

 

Thierry

0 Kudos
2,523 Views
pgo
Senior Contributor V

Dear Thierry,

 

The DLL provided is a minimal implementation of the USBDM-JM60 entry points that where used by the sprite.  The later one is probably using different ones or additional ones - OSBDM-JM60 has rather a lot of overlapping entry points!

 

I'll have a look at the newer version when I have a chance and hopefully it won't be much different.

 

bye

0 Kudos
2,523 Views
thm59
Contributor II

Thank you, PGO

 

I post a simple project (led  toggling) fully configured  running on the DEMOQE128 for those who should be interested to try.

Unzip the project in a temporary folder and import it with "import existing project into worskspace". I use Eclipse CDT with the Zylin embedded cdt from http://www.zylin.com/zylincdt

 

best regards

 

thierry

0 Kudos
2,523 Views
thm59
Contributor II

Hello (aigain), Pgo

 

H. Laided has released a dll allowing the CFFlasher (free flasher for v2 coldfire) to work with the tblcf. http://hlaidet.pagesperso-orange.fr/H_TBLCF.htm

 

The m68k-elf-sprite supports the tblcf (see my previous post)

If the usbdm can emulate the tblcf, normally, this should also be a free flashing solution for V2 devices.

 

thierry

0 Kudos
2,523 Views
pgo
Senior Contributor V

Dear thierry,

 

I've uploaded to Sourceforge a DLL to allow the use of USBDM devices with CFFlasher.  It was rather easier to do than I expected,

 

Let me know if there are any problems

 

bye

 

0 Kudos
2,523 Views
pgo
Senior Contributor V

Dear thierry,

 

I've updated the files on Sourceforge.  They should work with the current version of Codesourcery Lite.

 

I would appreciate if you could test these when convenient.

 

I'll have a look at CFFlasher.  Do yo know if the source is available for the DLL being used?

 

bye

 

0 Kudos
2,523 Views
thm59
Contributor II

Hello, Pgo

 

The dll of sourceforge works with the latest version of Codesourcery.

I have made preliminary test on a DEMOQE (mcf51qe128) board and below are preliminary findings :

 

1)  the sprite seems detecting 2 devices (only one is present) :

 

CodeSourcery ColdFire Debug Sprite (Sourcery G++ Lite 2010.09-39)
pe: [speed=<n:0-31>&memory-timeout=<n:0-99>] P&E Adaptor
ccs: [timeout=<n>&speed=<n>] CCS Protocol
  ccs://$Host:$Port/$Chain_position - Command Converter Server
tblcf: TBLCF Interface
osbdm: Open Source BDM
  osbdm://0/ - OSBDM device
  osbdm://1/ - OSBDM device

 

2) the usbdm is working perfectly fine in  debugging the µC with the code in flash

 

However, the usbdm doesn't wand to load the code in ram (I used the correct linker script) :

In response to the gdb "load" command :

 

Loading section .text, size 0x7d4 lma 0x800000
m68k-elf-sprite: Can't write a block of memory: OSBDM error code 2
m68k-elf-sprite: Memory write verification failed; config file error?
Load failed

 

I will perform additional test s with the DEMOAC (mcf51ac256) tomororow.

I have'nt the source code of the tclcf - CFFlasher dll but Henri Laidet kindly share his work. Ask him, he wil certainely send you his code (his email addrres is on his website) .

 

Best regards and thanks for your work.

Thierry

 

0 Kudos
2,524 Views
pgo
Senior Contributor V

Dear Thierry,

 

The appearance of two targets is expected.  This is the method used to determine if the BDM is to look for a CFV1 or CFVx target.  See the Readme file with the DLLs.

 

I've fixed the problem with RAM targets I believe - See the Late updates on version 4.5.

 

The V4.5 online documentation also now has a HOW-TO for the method used with a RAM target and Codesourcery.

 

CFFlasher is now also supported.

 

bye

0 Kudos
2,523 Views
thm59
Contributor II

Hello, Pgo

 

After some tests, i got an error with debug in ram with my DEMOAC (MCF51AC256) :

 

Loading section .text, size 0x7d4 lma 0x800000
m68k-elf-sprite: Memory write verification failed; config file error?
Load failed

 

It seems not to be a write error, but only a verification error.

 

On a MCF51QE128 (DEMOQE), it is OK.

 

In addition I always make the same test with the embedded multilink, to avoid soft issues

 

best regards

 

Thierry

0 Kudos
2,523 Views
pgo
Senior Contributor V

Dear Thierry, 

 

Can you post or email a Zip of the project if it isn't confidential?

 

bye

0 Kudos
2,523 Views
thm59
Contributor II

Hello, Pgo

 

The project is attached, it is a very simple "led toggling" test project.
It run on a  DEMOAC (MCF51AC256A)


Hereater is the output wit the on-board P&E multilink

target remote | m68k-elf-sprite pe: m51ac256evb-33
m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-12 : DEMOAC (PE5018347))
m68k-elf-sprite: Target reset
0x00000000 in ?? ()
load
Loading section .text, size 0x7d4 lma 0x800000
Loading section .eh_frame, size 0x4 lma 0x8007d4
Loading section .rodata, size 0x50 lma 0x8007d8
Loading section .data, size 0x8 lma 0x800828
Start address 0x800400, load size 2096
Transfer rate: 4 KB/sec, 524 bytes/write.
set $pc= _start
br main
Breakpoint 5 at 0x80055e: file ../main.c, line 46.
continue

Breakpoint 1, main () at ../main.c:46
46       SOPT=0X53;



Here is the output using the USBDM, with exactly the same elf  file

target remote | m68k-elf-sprite osbdm:0 m51ac256evb-33
m68k-elf-sprite: Target reset
0xffffffff in ?? ()
load
Loading section .text, size 0x7d4 lma 0x800000
m68k-elf-sprite: Memory write verification failed; config file error?
Load failed
set $pc= _start
br main
Breakpoint 1 at 0x800558: file ../main.c, line 42.
continue
m68k-elf-sprite: Memory write verification failed; config file error?
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x800558: (undocumented errno -1).

Best regards

 

Thierry

 

0 Kudos
2,523 Views
pgo
Senior Contributor V

Dear Thierry,

 

I don't have a AC256 to test with at the moment but I have the following comments:

 

I'm unable to test your project directly since I don't have the CYGWIN tool chain installed in eclipse.  I use the support for external tools that's in the latest CDT.  The project was set up as described here:

 

http://usbdm.sourceforge.net/USBDM_V4.5/USBDM_JS16/html/code_sourcery_page.html

 

I've set up a project using your settings (as near as I can with changes for the above) and it builds and downloads to a MCF51CN128 without error.  It doesn't debug because of differences in the chips but goes far enough to show the problem is not occuring.

 

 

symbol-file C:\\Peter\\Development\\CodeSourceryTry\\TryMCF51AC128\\Debug\\TryMCF51AC128target remote | m68k-elf-sprite osbdm://0/ m51ac256evb-33m68k-elf-sprite: Target reset0x003e202e in ?? ()load C:\\Peter\\Development\\CodeSourceryTry\\TryMCF51AC128\\Debug\\TryMCF51AC128 Loading section .text, size 0x7d4 lma 0x800000Loading section .eh_frame, size 0x4 lma 0x8007d4Loading section .rodata, size 0x50 lma 0x8007d8Loading section .data, size 0x8 lma 0x800828Start address 0x800400, load size 2096Transfer rate: 3 KB/sec, 524 bytes/write.tbreak mainTemporary breakpoint 2 at 0x80055e: file ..\src\main.c, line 46.continuem68k-elf-sprite: Can't read a debug register: OSBDM error code 1

 

I will upload a debug version of the osbdm DLL to sourceforge shortly and if you like you can try that version.  It will produce a log file (in %APPDATA%/usbdm) which will shown exactly what the sprite is telling the BDM to do.

 

From the information you posted it would appear that it is actually failing immediately after or at the reset since the  line

 

 

0xffffffff in ?? ()

 is incorrect - This is meant to be the PC value after reset and it should never be odd!

 

Finally there is an errata on early AC128s relating to debugging that might be affecting this.

 

Bye.

 

 

 

0 Kudos
2,523 Views
pgo
Senior Contributor V

Dear Thierry,

 

I've uploaded yet another version of the DLL that should fix the problem with the AC256 I hope.

 

It is due to the m51ac256evb-33.xml file changing the clock speed of the target.  The USBDM BDM only resynchronizes when the target status is read.  This is not occurring so the connection with the target is lost.

 

The modified DLL rather crudely resyncs on every memory/register read.  This will slow it down somewhat but should be reliable.

 

bye

0 Kudos
2,523 Views
thm59
Contributor II

Re-hello, Pgo

 

I have buy an USBDM for CFV2.

 

Next week (or when I will receive it), I could give you some feedback (with MCF5213EBV) if you are interested.

 

best regards

 

Thierry

 

 

0 Kudos
2,523 Views
digit
Contributor I

I'm kind of in a different boat as I own a PE USB-ML-CFE / PE_USB_ML  (PE USB Coldfire Multilink).  I request for help here as people here seems to have more knownledge than useless people at Freescale.  I'm using CodeSourcery lite, Eclipse on MCF52233.  I'm getting sick of cfflasher GUI.  I just need a command line tool or Eclipse feature to flash my MCF52233 device.

 

cfflasher command line interface ?  Yeah, right...

 

Back in 2006 I have reported an issue where CFFlasher command line was broken (version 3.1.2 at that time).  I have received that great answer !  Btw latest version 3.1.10 still as the same bug...

 

we would not be able to accommodate your requested change.We have verified that the CLI does not fully function. There are noplans at this time to correct this. You will have to use the GUI, orpurchase a tools for your needs. (P&E makes a CLI for ColdFire)

 

https://community.freescale.com/message/21082#21082

 

 So is there any alternative for cfflasher to flash MCF52233 device using USB-ML-CFE (PE-USB-ML) ?

 

Regards,

0 Kudos
2,523 Views
thm59
Contributor II

Hello, Pgo

 

You are really impressive.

It works perfectly :

 

 

target remote | m68k-elf-sprite osbdm:0 m51ac256evb-33
m68k-elf-sprite: Target reset
0x0000061e in ?? ()
load
Loading section .text, size 0x7d4 lma 0x800000
Loading section .eh_frame, size 0x4 lma 0x8007d4
Loading section .rodata, size 0x50 lma 0x8007d8
Loading section .data, size 0x8 lma 0x800828
Start address 0x800400, load size 2096
Transfer rate: 5 KB/sec, 524 bytes/write.
set $pc= _start
br main
Breakpoint 3 at 0x80055e: file ../main.c, line 46.
continue

Breakpoint 1, main () at ../main.c:46
46       SOPT=0X53;

 

Thank you very much.

 

Thierry

0 Kudos
2,523 Views
thm59
Contributor II

Hello, PGO

 

I confirm that the ram operation is now working perfectly.

With Eclipse, Codesourcery lite, your V1 flash programmer and CFFlasher, we get a complete fully unlimited free and high-level gcc toolchain for Coldfire µCs.

Best  regards and thanks again. This is really an amazing work.

 

Thierry


 

0 Kudos