Building for FRDM-KL25Z on Kinetis Design Studio

[sgraves]

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

[podonoghue]

I have been working an a C++ version for a stand-alone programmer and it looks like some of the changes have crept into this version. (https://github.com/podonoghue/usbdm-kinetis)

I have fixed these and pushed an update.

It now builds with KDS (and Eclipse I would expect) with the USBDM plugin.
The OpenSDA build for FRDM boards is a composite device since it supports CDC (serial) communication.
I tested it on a FRDM-KL46Z programming with local target and it worked OK.
I will test with a FRDM-KL25 with an external target tonight.

Finally - About your original problem. I suspect it is due to the bootloader code that is in the KL27.
Have a read of this posting as it may help: #2

I confirmed use of a FRDM_KL25 programming an external device (not KL27!) with the firmware provided with the current USBDM version. I don't have a stand-alone KL27 to test this arrangement with however using a FRDM-KL27 board the software worked fine with the on-board chip so I would not expect any problems with the other arrangement.

bye

[sgraves]

Peter,
Thank you very much, you have fixed the build errors.

I still had problems with the usbdm-make. I am not doing something right, but got it to work by setting all the arm-none-eabi-xx binary files to "Run As Administator". My KDS is installed in C:\Freescale\KDS_v3, I suspect it doesn't run in the right environment from there.

In any case, the code builds the elf file but usbdm-make fails on the post-build step. The makefile has the following for post-build

-@echo 'Create hex file for bootloader'
-arm-none-eabi-objcopy -O srec OpenSDAv1.elf OpenSDAv1.sx
-@echo ' '

I think the dashes are the problem. So I manually run the command and get a binary. When I load it into the K20 and connect it to the PC (Windows 10) and I get a USB Composite Device with a "This device cannot start. (Code 10)" Device status. It shows a Hardware ID of

USB\VID_16D0&PID_06A5&REV_004<
USB\VID_16D0&PID_06A5

As you know, working code gives me a hardware ID that has "&MI_00" and "&MI_01" on the end.

BTW, I have lifted the SWD and reset pins on the KL25 processor to remove any interaction from it with my processor. Even with that the connection to the debugger is flaky.

So I have something misconfigured in the build of the firmware. What do you think it is?

Thanks,
Steve

[sgraves]

Peter,
I haven't got a good build of the firmware. I am hoping you can give me insight into where the USB hardware ID is wrong.

I have decided to spend a little time understanding the firmware and where I might try to make changes when I get working code set.

When my processor is erased, the reset line has the oscillating waveform that others have seen. I have played around with changing the capacitance on the reset line which does influence the frequency. I suspect I can make this work by playing around with that. But I see that others have had this problem with new chips and I think we can make the firmware more robust and make it work when the reset line is misbehaving. According to the log, it fails when attempting a Mass Erase (Chip Detect seems to work most of the time even though the log shows "Target reset pin timeout (rise)" errors. BTW, I am using the "UsbdmFlashProgrammer-debug.exe" program for testing. It is very helpful having these tools, you are to be commended.

Hopefully, I can help find where the firmware can be improved since I have a misbehaving system. For example, looking at the mass erase code in firmware I see that it toggles the Green LED. A clue is that the Green LED blinks once at about a one second interval before failing.

BTW, this is a fresh from the factory IC. I have not loaded boot code into it. That is probably another way to solve my problem.

So looking at the firmware, I see that the swd_readReg and swd_writeReg have no retries if the processor responds with anything other than a 1 (SWD_ACK_OK), 2 (SWD_ACK_WAIT) or 3 (SWD_ACK_FAULT).

I am reading the debug documentation. It appears that something happens when the MASS_ERASE bit is set in the MDM-AP.Control register to cause the SWD to quit responding. Since it appears to only take one failure in the above functions it could be some timing issue.

Steve

[sgraves]

Peter,
Below is the verbose log on the GDB Server when I try to load code with KDS (using your firmware). I have also attached the log file .

I am thinking there is more happening here and the possibility of more information for you (and me).

Steve

Using any suitable USBDM interface
Server created @localhost:3333

=====================================
New client connection from localhost:52973 accepted

=====================
Dropped connection

=====================================
New client connection from localhost:52974 accepted
Loading register description from device database
Number of hardware breakpoints = 2
BDM Open OK
Sending target description
Sending register description
Sending register description
Reading Registers
User reset of target
Reading Registers
Erasing flash[0..9FFF] - ignored
Creating flash image
Writing to flash image[0..BF]
Writing to flash image[400..40F]
Writing to flash image[410..B9F]
Writing to flash image[BA0..130F]
Writing to flash image[1310..1A9F]
Writing to flash image[1AA0..222F]
Writing to flash image[2230..29AF]
Writing to flash image[29B0..313F]
Writing to flash image[3140..38CF]
Writing to flash image[38D0..406F]
Writing to flash image[4070..480F]
Writing to flash image[4810..4F9F]
Writing to flash image[4FA0..572F]
Writing to flash image[5730..5EBF]
Writing to flash image[5EC0..664F]
Writing to flash image[6650..6DCF]
Writing to flash image[6DD0..755F]
Writing to flash image[7560..7D0F]
Writing to flash image[7D10..84AF]
Writing to flash image[84B0..8C5F]
Writing to flash image[8C60..93FF]
Writing to flash image[9400..9B9F]
Writing to flash image[9BA0..9D23]
Writing to flash image[9D24..9D2B]
Writing to flash image[9D2C..9D2F]
Writing to flash image[9D30..9D33]
Writing to flash image[9D34..9DA3]
Programming Target Flash....
Programming Flash Image failed: Execution of TCL script returned an error
Error response sent: E.fatal.Flash programming failed
Error response sent: E.fatal.Closing connection

=====================
Dropped connection

GDBServer.log.txt

[sgraves]

Peter,
Sorry the last attached log file was not from the GDB Server session in KDS. KDS started its own non-debugged session. I am now having KDS using UsbdmGdbServer-debug.exe and have the proper log. It is attached.

Steve
GDBServerToday.log.txt

[sgraves]

Peter,
I am trying to understand these GDB Server log files. The last showed a flash verification error. I have another that shows an error on Mass Erase. It seems to have the same root cause as the "UsbdmFlashProgrammer-debug.exe" log files.

I am getting a little desperate. I am supposed to meet with my customer tomorrow. I want to show him some progress on his project. Unfortunately, he won't see fixing the debugger as progress. And I haven't even done that!

Steve

GDBServer.201612122306.log.txt

[sgraves]

Peter,
Our srecord files are of different lengths. I am trying to compare them to get a clue why mine is smaller than yours. It would give more information to compare the map files. I am attaching mine for you to see. If you send me yours, I will do the leg work.

Thanks,
Steve
OpenSDAv1.map.txt

[sgraves]

Peter,
I am also attaching the console output for a clean build. As one can see, no warnings or any complaints by the toolchain.

Steve
BuildConsole.txt

[podonoghue]

Hi Steve,

I have been unable to reproduce your problems with a FRDM_KL27 board which is the only KL27 chip I have, I have ordered a chip and will do some testing when it arrives (about a week - perhaps longer due to Christmas).

Testing with a stand-alone KL26 which is similar I get the usual RST bounce due to a blank chip:

On some occasions I have found it necessary to do a mass erase to get the chip into a usable state but usually programming with the Mass-erase option is effective.
The following is an example of the start of the Mass-erase sequence - Note that the Reset line is held low.

Could I get you to post your circuit please?
A few issues that have appeared on a few occasion are:

• Connections to the NMI line. This may cause the programming to abort unpredictably.
• Inadequate power supply bypass ( as above)
• Too much capacitance on RESET line (affects the ability of the programmer to reset in a timely fashion)

Finally I will look at the USB issues when I have time which won't be for a little while. It is unlikely that modification of the BDM firmware will help with your issue as the detailed reset connection sequence is mostly controlled by the C code running on the PC not the BDM firmware. In particular the TCL scripts control most of this (see Kinetis-KLxx-flash-scripts.tcl).

bye

[sgraves]

Peter,
I have captured the USB connection sequence for the two code sets. On the USB_DESCRIPTOR_TYPE command the good code responds with the interface numbers 0,1 & 2 for the interface descriptors. The bad code responds with interface numbers 0, 0 & 1. I just found this and haven't looked at the code yet. Just putting it out there for you in case you see this and it triggers something.

Thanks,
Steve

[sgraves]

Peter,
I have that exact waveform. I just want to try to play around with the firmware since I have a misbehaving board, but my build is not right. As I stated above, the USB is not registering itself correctly. Hopefully, that is all that is wrong with the build. If I get a good build, I can try things like putting a short delay after the Mass Erase before attempting to read the status register.

Thanks,
Steve

[sgraves]

Peter,
In USB.c, I changed

#define CDC_COMM_INTF_ID 0
#define CDC_DATA_INTF_ID 1

to

#define CDC_COMM_INTF_ID 1
#define CDC_DATA_INTF_ID 2

and the USB is now registering correctly. Now to find out if the rest of my build acts like your code.

Steve

[sgraves]

Peter,
I still have problems with the build. The device is registering correctly with Windows and I get the Debugging Interface/USBDM BDM Interface in the Device Manager. The UsbdmFlashProgrammer-debug is not complaining about no device like it did before, but now it says "Device not responding or busy". If I try anything it asks me to power cycle the target. Which doesn't work.

I downloaded a zip file from Github, instead of forking. Were the above defines wrong in the code I got? If we can understand why that happened, then maybe it will reveal where this other stuff is happening.

I can fork the code if that is needed.

Thanks,
Steve

[sgraves]

Peter,
I have a build that appears to work like yours. I used a virtual XP machine, installed KDS, USBDM, etc and set up a build there. BTW, I had to make the changes to USB.c. The srecord file still doesn't match yours, but it is closer in size. More importantly when loaded into the debugger it connects and fails in the same way on Mass Erase. I will be trying out some things to make it stay connected. The timer as I mentioned and maybe some retries on the read of the status register after Mass Erase.

It appears that there is a problem with my Windows 10 environment and building your code. I had been playing around with various compatibility settings on the executables, but it didn't seem to work. I will try to figure out what is happening. With the Windows XP builds I have object files that work and Windows 10 ones that don't. I should be able to use some of the inspection tools for object files to see how they differ and maybe track down what is going on.

Thank you for your help so far. I think I am kind of on my own at this point. I have a misbehaving processor and I should be able to track down why it doesn't want to maintain communication. I will keep you updated on my findings. You have a great system supporting a wide range of processors, programming environments and debuggers. You should be proud of your achievements! I hope I can contribute a little to your success.

Steve

[podonoghue]

Dear Steve,

I have corrected a few more errors with the USB code and update the repository. I think I must not have tested the previous version properly (probably downloaded the wrong file to the board!)

If you want to test this version from scratch you can follow the following steps:

• Download the Zip of the repository
• Extract to a folder
• Import the USBDM_Kinetis project folder into KDS or Eclipse with the USBDM plugin installed. Note this is not a Codewarrior project - it is a USBDM project.
• This should build with no changes or errors!
• Download the OpenSDAv1_Unique_ID.sx file to the FRDM board in bootloader mode. It should not be necessary to disconnect the onboard KL25 providing you have previously programmed it with the BootloopMKL.elf file. (This is not relevant since you have already disconnected the pins).

As mentioned earlier, if you want to play around with the connection/reset sequence you should be looking at the TCL scripts and also the USBDM interface DLL code and that is where most of the work is done for the Kinetis targets. The firmware is mostly a dumb slave.
Have a look at this file:
https://github.com/podonoghue/usbdm-eclipse-makefiles-build/blob/master/Usbdm_DLL/src/armInterface.cpp
In particular the resetARM() code.

bye

[podonoghue]

Dear Steve,

I have retested with an stand-alone MKL27Z64 device and have been unable to get it to miss-behave,
I have modified the mass-erase sequence for MKL devices (for better behaviour on programmers with Target Vdd control). It might be worth re-testing with the modified files on Github.

bye

[sgraves]

Peter,
My main problem was voltage. I am interfacing to a FLIR Lepton sensor that runs at 2.8 VDC. The KL27 will operate at that voltage, but it doesn't communicate with the debugger well at that voltage. I had tested the debugger when the KL27 was running at 2.8 and 3.3 and it wasn't working at either voltage. I believe I had other issues that caused it to fail at 3.3 VDC before. (Probably had bad debugger firmware). Now with proper firmware it is very reliable at 3.3 V and not so reliable at 2.8 V. And I have built the firmware from your new code set (on XP) and it is working just like the code you built. I still have issues with Windows 10. I will troubleshoot them after I get further along on my project.

With a working debugger, I have made great progress on my project, my customer is happy, I am happy. Your system is making it possible. I am very thankful for your work on this. It is not only the low cost, but that I have access to the entire system that makes this so valuable to me. I have been an engineer for many years and I have dealt with vendors that had bugs that took me many days to convince there was a problem and then a long time to get them to fix it. I love open source!

Thank you very much for your work.
Steve