Reusing SWD_DIO and SWD_DIO about usbdm-firmware HOT 2 OPEN

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:[email protected]] Sent: Thursday, 7 December 2017 4:31 AM To: podonoghue/usbdm-firmware <[email protected]> Cc: Subscribed <[email protected]> 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 GitHub<#5>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABw1A63juXtAqNGwOp8hHcgT89lMoIh-ks5s9s9MgaJpZM4Q4TUm>.