search

podonoghue / usbdm-firmware

Firmware for USBDM BDMs
47 stars 28 forks source link

Reusing SWD_DIO and SWD_DIO #5

Open RGassmann opened 6 years ago

RGassmann commented 6 years ago

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

podonoghue commented 6 years ago

Hi Roman,

The reset strategy for ARM devices was changed in V4.12.1.200 to support device family specific reset strategies. This was needed for LPC devices. For Kinetis devices the default reset is to use Vendor Reset (software) using the MDM-AP interface as, in many cases, it is possible to program these devices without a reset pin connected. In practice this is unreliable in some cases and if the default reset fails it is meant to try other methods – usually a pin reset. There were some errors in implementing this fall-back. This above strategy accounts for the communication before a Pin reset.

When doing detect device it doesn’t know the type of device so tries methods applicable to each devices being probed for. It will try multiple times. I think this accounts for the successful outcome since for some device the default reset will be pin-reset.

You should find it more reliable with the current release.

It should be possible to program devices even when the SWD pins are programmed for other uses but there are some known problems with some devices. Especially early Kinetis devices. You obviously can’t debug without these pins.

bye

From: Roman Gassmann [mailto:notifications@github.com] Sent: Thursday, 7 December 2017 4:31 AM To: podonoghue/usbdm-firmware usbdm-firmware@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [podonoghue/usbdm-firmware] Reusing SWD_DIO and SWD_DIO (#5)

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/podonoghue/usbdm-firmware/issues/5, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABw1A63juXtAqNGwOp8hHcgT89lMoIh-ks5s9s9MgaJpZM4Q4TUm.

RGassmann commented 6 years ago

Hi Peter, first of all thanks for your fast answer. After your info, that you have changed the reset part, to also support LPC-Devices, I tried the current release. While I had no problem programming my device with the sequence of my last post, I ran into several problems with the GUI-Programming.

  1. "Detect Chip" will report "Execution of TCL script returned an error" every first time. Independent of the Reset Method. After the first run the device is in reset and thus a secound run of "Detect Chip" works.

  2. "Program Flash" fails with report " BDM has no connection to target". Also independent of the Reset Method. The only way to programm a device is by running "Detect Chip" first.

Is it possible that the command sequence and the GUI-Programming dont use the same code sequence?

Unfortunately I didn't had time to examine this further. I hope I'll find some time during the next few days or at least during the X-Mas days. I'll come back to you as soon as I'll have more infos.

Thanks,

Roman