Hello, I already use the USBDM_JMXX board on a Windows PC, but is there some support for OS X? Can I install the eclipse plugins on a mac machine?
Thanks in advance.

Hi Peter,

finally the time has come that I was running out of GPIO-Pins on one of MKL17z256VFM4 Projects.
So after a careful check of every I/O I realized that I could use the SWD_DIO and SWD_SCK to drive my status Led's. As that would be sufficient for my project I checked the USBDM-Schematics (FRDM-Board I am using the OpenSDAv2_0_Unique_ID.bin Verison 4.12.1) and thought that it should work fine.
To be 100% sure I made a little test HW where I connected two LED's (with a 1k resistor) to the DIO and SCK Inputs and wrote a little program that toggles those LED's. Now of corse programming it worked the first time. Unfortunately after that the programming did not work anymore. So I experimented a little an found the following:

1. A further programming of the device is possible if first a "Detect Chip" is issued. (Since after that the MCU is in some sort of Reset-State)

2. I noted that the DIO-LED flashes oddly for a very short time when I execute the following sequence "UsbdmFlashProgrammer -target:arm -device:MKL17Z256M4 -erase:Mass -program image.srec -execute" without calling "Detect Chip" first.
   2.1. As the MCU at that time didn't stop working I had the feeling that the MCU was never in reset mode. So I short-circuited the RST-Signal with GND and Run the sequence again. As soon as the DIO-LED started to flash I let the RST-Signal lose. This time the programming was successful. That meant that I had to investigate further. Now as I attached the Oscilloscope I expected to see the following signals:
   First RST from high to low after some time Data on SWD_DIO and SWD_SCK,
   but what I found was that the RST signal wasn't pulled low ever. So I reprogrammed my device back to the point where DIO and SCK are not configured as OUTPUTs and run a second programming with an attached oscilloscope.
   The result astonished me even more as at first some Data on SWD_DIO and SWD_SCK is sent followed by a RST-low signal.
   This leaves me with the following questions:

3. Why is there a data transfer before the RST-Signal is pulled low.

4. What exactly happens during time right before the RST-Signal is pulled low?

5. Why isn't this problem not present in the "Detect Chip"-procedure. Whats the difference.

6. Do I have a chance to use the DIO ans SCK pins for other purposes other than programming?

Can you please enlighten me.
Thanks for your help,
Roman

I have two PCBs with MCF5407 with external NOR flash. There is also a BDM 26-pin connector available. I would like to copy flash contents from one board to another. Which hardware from your project could I use?

Hi,

using GCC12.2, libwxbase3.2-1 and libwxgtk3.2-dev and their dependecies for compillation. (the old ones what is reffered in the "Linuxpackages" are not available in the new distros)

This error also happened on old Debian buster distro (GCC 8.3)

-- Building usbdm-interface-arm.x86_64-linux-gnu/BdmInterfaceCommon.o from src/BdmInterfaceCommon.cpp
g++ -fPIC -O3 -g3 -m64 -std=gnu++17 -Wall -shared -fvisibility=hidden -fvisibility-inlines-hidden -DCOMPILE_USBDM_INTERFACE_DLL -Isrc -I../Shared/src -MD -c src/BdmInterfaceCommon.cpp -o usbdm-interface-arm.x86_64-linux-gnu/BdmInterfaceCommon.o
In file included from ../Shared/src/BdmInterface.h:37,
from src/BdmInterfaceCommon.h:11,
from src/BdmInterfaceCommon.cpp:39:
../Shared/src/AppSettings.h: In member function ‘AppSettings& AppSettings::operator=(const AppSettings&)’:
../Shared/src/AppSettings.h:219:17: error: no match for ‘operator!=’ (operand types are ‘const AppSettings’ and ‘AppSettings’)
219 | if (other != *this) {
| ~~~~~ ^~ ~~~~~
| | |
| | AppSettings
| const AppSettings
make[2]: *** [Target.mk:95: usbdm-interface-arm.x86_64-linux-gnu/BdmInterfaceCommon.o] Error 1
make[2]: Leaving directory '/opt/src/usbdm-eclipse-makefiles-build/BdmInterface_DLL'
make[1]: *** [Makefile-x64.mk:12: usbdm-interface-arm] Error 2
make[1]: Leaving directory '/opt/src/usbdm-eclipse-makefiles-build/BdmInterface_DLL'
make: *** [Makefile-x64.mk:59: build-BdmInterface_DLL] Error 2
64-bit Make failed

Hi,
Adding RP2040 chip to the debugger/flash programmer (SWD) ?

Hi,

your HCS12 tower firmware (USBDM_TWR_HCS12_V4.sx) is running now on my DEVKIT-S12G128 after I had to modify the hardware to make the connection between USBDM and target work. I have two of those boards and the problem was the same on both of them.
The problem is on the side of the MC9S08JM60 where the TBGND in- and out-pins are decoupled by a 4k7 resistor. When the TBGND_OUT (PTF4) tried to pull low, the voltage behind the resistor and on the input of the HCT45 buffer was not low but at around 2.5V. For the buffer input, this was still detected as high level. I fixed this by reducing the 4k7 resistor to 1k.
This is still a mystery to me as the pull-up resistors of the MC9S08JM60 should be weak in comparison to the 4k7 and the datasheet of the buffer does not seem to mention a pull-up.

As far as I have seen, the pull-ups are enabled by default in the firmware and maybe it would solve the issue to disable it at least for the TBGND_IN (PTF1) pin. I would be happy to test this if you would like me to.

Anyway, thanks a lot for your brilliant work!

Best regards,
Max

Hi,

(Using Linux, Debian BookWoorm, latest Wx libs)

The UsbdmFlashProgrammer and the GSBServer both got segfault at same point.

firmware loader (HCS), FlashDump app works fine...

BackTrace of Flasprogrammer:

Reading symbols from UsbdmFlashProgrammer-debug...
(No debugging symbols found in UsbdmFlashProgrammer-debug)
(gdb) run
Starting program: /opt/src/usbdm_4.12.1.300-1-x86_64/usr/bin/UsbdmFlashProgrammer-debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff15866c0 (LWP 31615)]
[New Thread 0x7ffff0d856c0 (LWP 31616)]
[New Thread 0x7fffebfff6c0 (LWP 31617)]

Thread 1 "UsbdmFlashProgr" received signal SIGSEGV, Segmentation fault.
0x00007ffff7f6b54c in ?? () from /usr/lib/x86_64-linux-gnu/usbdm/libusbdm-device-database-debug.so.4
(gdb) bt
#0 0x00007ffff7f6b54c in ?? () from /usr/lib/x86_64-linux-gnu/usbdm/libusbdm-device-database-debug.so.4
#1 0x00007ffff7f6b597 in ?? () from /usr/lib/x86_64-linux-gnu/usbdm/libusbdm-device-database-debug.so.4
#2 0x00007ffff7f65db6 in DeviceDataBase::getDefaultDevice() ()
from /usr/lib/x86_64-linux-gnu/usbdm/libusbdm-device-database-debug.so.4
#3 0x00007ffff7f67e6e in DeviceDataBase::loadDeviceData() ()
from /usr/lib/x86_64-linux-gnu/usbdm/libusbdm-device-database-debug.so.4
#4 0x00005555555c8190 in ?? ()
#5 0x00005555555c70a1 in ?? ()
#6 0x00005555555c76b5 in ?? ()
#7 0x00005555555bd49d in ?? ()
#8 0x00005555555bc2d9 in ?? ()
#9 0x00007ffff72a306b in wxAppConsoleBase::OnInit() () from /lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#10 0x00005555555bb953 in ?? ()
#11 0x00005555555c4adf in ?? ()
#12 0x00007ffff731feea in wxEntry(int&, wchar_t**) () from /lib/x86_64-linux-gnu/libwx_baseu-3.2.so.0
#13 0x00005555555bae3e in ?? ()
#14 0x00007ffff704618a in __libc_start_call_main (main=main@entry=0x5555555bae1c, argc=argc@entry=1,
argv=argv@entry=0x7fffffffdff8) at ../sysdeps/nptl/libc_start_call_main.h:58
#15 0x00007ffff7046245 in __libc_start_main_impl (main=0x5555555bae1c, argc=1, argv=0x7fffffffdff8,
init=, fini=, rtld_fini=, stack_end=0x7fffffffdfe8)
at ../csu/libc-start.c:381
#16 0x0000555555580501 in ?? ()
(gdb)

Does the firmware for opensda support MC56F84000 DSC chips?

It looks like the current firmware require the non-free Code Warrior to compile. How about porting it to the free Small Device C Compiler?

I am using a modified FRDM-KL25Z board to debug a KL27Z design. The debugger is flaky and works sometimes, but mostly doesn't work. Using the debug log in the AppData I can see that it is talking to the processor but doesn't like that the reset line doesn't do what it is expecting. I can't fix the reset line, but it appears that the debugger should work even if the reset line is misbehaving. So I decide to "fix" the firmware. I try to import into KDS and build the USBDM_Kinetis firmware. There are multiple issues. One is that the complier won't work correctly when called by usbdm_make. I create a new project and start adding files to build. Another issue is that it appears that all "c" files need to be build as c++ files. On line 305 of USB.c there is an unterminated #if. That error alone makes me think that this code set does not build. I have managed to get it to build, but it connects to USB as a composite device and clearly is not the same code that my debugger is presently running. Where is the proper code? Am I doing something wrong setting up this code?

Thank you for your help. This is an awesome tool. I appreciate having it as an option. I try not to be a bother, but I am getting very little return on the hours I have spent and need to use my call a friend card.

Steve
usbdm.log.txt

Hi pgo,

recently I got the FRDM-KL27z-Board which I of corse wanted to use with the USBDM right away.
While the code of a simple flashing Led was working quickly, I noticed that the uC has a start delay of 3-5Sec. My first thoughts where that this has to do with the bootloader. Unfortunately that wasn't the case. After a discussion with a supporter I got a bin file which should work. Unfortunately my board still exerienced the delay. After this setback I tried to download the same s19/srec file with the OpenSDA. And voila it started up right away. And even my simple flashing led - Programm starts right away if I download it via OpenSDA but will experience a delay of 3-5Sec if downloaded via USBDM. This fact leads me to the assumption, that USBDM can not right to the entire flash of the uC (maybe some protection mechanism?). The same effect can be experienced on the MKL17 (which is nothing else than the MKL27 without USB).
Is this a known Issue to you? I would be glad if you could look deeper into this issue. If you need sample codes I'd be happy to provide you with my samples.
Looking forward to hearing from you.
Best regards,
Roman