OpenSDA on Vybrid

[anthony_huereca]

OpenSDA is a low‐cost debug/programming interface embedded in certain Freescale evaluation boards. It handles debug communications between the PC and target via USB. It uses a Kinetis K20 50Mhz chip on the bottom of Vybrid tower board to run firmware developed by P&E that acts as a bootloader. This lets it run and load "apps" that add functionality to the OpenSDA circuit. For example, an app could allow debugging with DS‐5, or IAR. Or an app could turn OpenSDA into a virtual serial port so you can get serial data via a USB cable instead of using a RS232 cable. Or an app could allow drag‐and‐drop programming of flash devices like QuadSPI. The possibilities are very open ended. This is the same OpenSDA circuit found on Kinetis L boards.

The app will run every time power is applied to the OpenSDA circuit via J3.

To load a new app, hold down the reset button (SW3) while power is applied via J3, then the firmware will enter a bootloader mode, and enumerate as a mass storage device. You can then drag and drop the new "app" into that MSD to load it. Power cycle the device, and then the new app will run.

Currently there are two apps available for Vybrid:

• CMSIS‐DAP ‐ For debugging with DS‐5 (default app on Rev A-F)
• Virtual Serial Port ‐ For creating a serial‐to‐usb bridge (default app on Rev G)

In the future there will be a Mass Storage Device (MSD) app that will include virtual serial port capability, plus enumerate as a mass storage device on your computer to drag‐and‐drop binaries to be programmed into QuadSPI, NAND Flash, and more.

Other things to note:

• Only RevG boards will have OpenSDA firmware
• All other revisions (except RevA) only have a basic CMSIS‐DAP firmware loaded onto the K20, and does *not* have the OpenSDA firmware/bootloader. Older boards cannot be upgraded since this firmware can only be loaded at the board manufacturer. RevA boards do not have either firmware.
• The OpenSDA circuit is only on the Vybrid tower board (TWR‐VF65GS10) and not other Vybrid boards.
• The OpenSDA bootloader firmware is proprietary. However some of the apps, like the CMSIS-DAP app, have source available and can be programmed stand-alone into the K20 circuit. This may be useful if developing your own board.
  • However note that this connection will be noticeably slower than using a dedicated debugger like D-Stream or JLink.

More information on OpenSDA can be found at:

http://www.pemicro.com/opensda

http://cache.freescale.com/files/32bit/doc/user_guide/OPENSDAUG.pdf

[jeremyesquirol]

Hi;

I cannot get my TWR-VF65GS10 Rev G tower board to upgrade to CMSIS-DAP.S19.

After giving the .S19 file to the bootloader, LASTSTAT.TXT says Programming... (always saying Programming....), and the SDA_INFO.HTM file has:

Board Name is: TWR-VF65GS

MicroBoot Kernel Version is: 1.04

Bootloader Version is: 1.08

Application Version is: 0.00

I do the steps :

- Enter bootloader mode

- Drag and Drop the file into bootloader MSD.

   Here, does i have to wait that LastStat.txt say "Completed" or must I power cycle ?
- If I power cycle, there is nothing happened, and my PC don't see the USB connection.
- if I wait, nothing is happened and LASTTEXT is always saying  "Programming..."

Furthermore, I'm unable to restore "the Virtual_Serial_Port.SDA"

EDIT : It seems it was because I was on Windows 8/8.1, i've tried with a pc on windows xp, doing the same steps and it works...

[anthony_huereca]

Microsoft changed how they handle MSD in Windows 8.1, which broke a lot of the OpenSDA bootloaders, including the one on Vybrid. MacOSX Yosemite has the same issue.

It should work on XP or Win7 machines.

-Anthony

[kef2]

On Win7 32bit machine bootload worked from ~10th attempt... There are also serious issues using OpenSDA from Vmware and VirtualBox Linux guest machines. I tend to believe that OpenSDA is bit broken...

Edward

[altia_mikey]

Updated 2/15/2014.

Ignore this information.  I was wrong.  The OpenSDA FW is just fine.

Long story short, turns out the problem was my music player application (Rhapsody) on Windows 7.  Rhapsody was auto-detecting the connected OpenSDA FW device as a "media player / storage" device and doing something to it (writing to it?) that caused the OpenSDA FW to go into a state where the JTAG lines were incorrectly held low.

Not sure if there's a way to make the OpenSDA FW more robust to avoid a situation like this.  Either way, my solution is to not use the locally installed Rhapsody application when doing active development with the Vybrid Tower HW.

================================================================================

================================================================================

I just got done resolving an issue wrt using Vybrid Tower board's (VF65GS10 rev G) J5 JTAG port that may help others.  It was impacted by which OpenSDA FW was installed on the K20 part.  (I just got done resolving an issue wrt using Vybrid Tower board's (VF65GS10 rev G) J5 JTAG port that may help others.  It was impacted by which OpenSDA FW was installed on the K20 part.  (forum thread)

Trying to use the (VF65GS10 rev G) J5 JTAG port with the OpenSDA CMSIS-DAP FW installed appears to be an undocumented, unsupported configuration.  At this point, it appears it's best to keep the Virtual COM Port FW installed when using the J5 JTAG header to develop / debug SW for the Vybrid part.

The OpenSDA CMSIS-DAP FW was incorrectly pulling the Vybrid's JTAG TMS signal low instead of letting it float per JTAG interface requirements.  This impacted the ability of the J-link to properly communicate with the Vybrid via JTAG.  Once I restored the Virtual COM Port FW to the OpenSDA / K20 part, the TMS signal was restored to the properly pulled up, 3.3V level.

Looking at the Vybrid Tower board schematic (rev G), the SI_SPI0_SOUT signal coming out of the K20 part is tied to the JTMS signal (Vybrid pad PTA11).  For some reason, the OpenSDA CMSIS-DAP FW is causing that signal to be driven low.  I would have expected the SI_SPI0_SOUT signal to remain in a high impedance state when the CMSIS-DAP port was not being used to actively download / debug FW.  Not sure if this is a bug in the CMSIS-DAP FW.

In summary, when using the J5 JTAG port to develop / debug, make sure OpenSDA Virtual COM Port FW is installed.

[naoumgitnik]

Hello Everybody,

We will try to take your critique into account.

Regards, Naoum Gitnik.

jiri-b36968

naoumgitnik

[davidpeter]

Any update on this issues, being able to drag and drop files to run?

[naoumgitnik]

Hello jiri-b36968,

May you comment on the "drag-and-drop" feature of the OpenSDA interface, please? Has it gotten fixed yet? - The symptoms had been described above in the message dated "Oct 9, 2013 11:43 AM".

Thanks in advance, Naoum Gitnik.

[davidpeter]

I have read the comments multiple time sand it does not appear to work. Also no support from P&E on the issue about the version as reported by the K20.

The unit always comes up in the BootLoader device mode.  With multiple attempts the has produced non-consistent behavior of the LEDs . The use to scan back and forth now nothing..

[naoumgitnik]

Thanks a lot for your quick reply, Jiri Kotzian!

Regarding "always goes into bootloader mode” and the "early TWR-VF65 module Rev.H version with old P&E bootloader version (004)” comment. - I am afraid it is something different; David, is this the board revision that you are using? Most likely , it is still the older Rev.G.

Regards, Naoum Gitnik.

[davidpeter]

Naoum

Our setup is:

PCB: 170-27442 REV G

IAR Compiler: 6.07

Information from the BOOTLOADER.SDA_INFO.htm

Board Name is: TWR-VF65GS
MicroBoot Kernel Version is: 1.04
Bootloader Version is: 1.08
Application Version is: 0.00
DUID is: 74823937-473181B3-3780C80D-B678E678
EUID is: 6AE3D036-A84B8719-187FAA1A-948168D6
TUID is: 74823938-18440358-453D9D5B-92389832
TOA is: 86B6E505-B30A537C-6928667C-86606BC1
TOA2 is: 86B6E505-7209C2E3-4FF66072-843CE8B1
SUID is: 86B6E505-5966D80F-37239805-8003EC65

We are attempting to get the IAR GettingStarted project running from the Configuration 'A5 Release QSPI to DDR'

Thanks for the exhange

[naoumgitnik]

Jiri Kotzian , does this information help?

/Naoum G.

[davidpeter]

In addition I NO longer see an OpenSDA port on my PC (windows 7 Pro).  Even after rebooting both the Vybrid brd and the PC

[jiri-b36968]

Hi Peter/Naoum,

P&E v1.08 equals to 004 mentioned before. If bootloader mode is active you will see:

If normal mode is active with default app (virtual serial port) you should see something like this:

where TWR-VF65GS is "disk" with Virtul serial chanel driver info

if CMSIS-DAP is loaded, then it behaves like USB Input device

/Jiri

[davidpeter]

Thanks Jiri. It appears after re-reading this thread a few times there has been a misunderstanding on side of the fence.  We were under the impression/idea that we can drag and drop a vybrid application, for example the IAR 'GettingStarted' ( QSPI to DDR Released) project and it would boot and run.

[jiri-b36968]

Hi Peter,

for direct programming of the Vybrid Tower module without debugger you can use Vybrid Manufacturing Tool ( Host Tool, U-boot source code and documentation to download OS images to a Vybrid processor)

Go to Hardware Development Tools, Vybrid Manufacturing Tool..

/Jiri

[jiri-b36968]

Hi Peter/Naoum,

Do not see any problem with "drag and drop". I'm always use same steps:

unplug TWR-VF65 module, press and hold button, plug an usb micro cable into J3, wait for LED D5 blinking, release the button, wait till new window appear, drag and drop the app, wait till it is copied (1-2 sec), close the window and unplug the module. What is not working for me is direct copy in File Manager (Total commander). Drag and drop is always without any problem (Win7, rev.G).

Regarding always go into bootloader mode: This happened on early TWR-VF65 module rev.H version with old P&E bootloader version (004). There have to be 007 version. Please check /RESET signal, if there correct level when button is not pressed - logic 1.

/Jiri

[adiroot]

I cannot get my TWR-VF65GS10 Rev G tower board to upgrade to CMSIS-DAP.S19.

After giving the .S19 file to the bootloader, LASTSTAT.TXT says Completed, and the SDA_INFO.HTM file has:

Board Name is: TWR-VF65GS

MicroBoot Kernel Version is: 1.04

Bootloader Version is: 1.08

Application Version is: 0.00

I can restore serial port functionality by giving Virtual_Serial_Port.SDA to the bootloader.

My colleague gets similar results with his tower board.  His board will not even accept the Virtual_Serial_Port.SDA file.

FWIW, the K60 tower board that I have works perfectly.

[jackblather]

adiroot,

Whenever I drop the .S19 file onto the K20, I always do a USB eject from Windows to make sure the buffers are flushed to the MSD before resetting/powerCycling the board. Hope that helps.

I quit using the Virtual Serial Port SDA. At speeds above 57600, it drops massive amounts of characters. Even at 57600, it drops a few characters. I opted to leave the CMSIS-DAP firmware loaded and configured the serial port jumpers to use the SER2 DB-9 serial port instead for SCI1. Doing this, I can run 115200 with no drops. For SCI2, I used jumper wires on J23 and J24 going to an external RS232 transceiver, so now I have two hard-wired UARTS without having to go through the K20.

I find I often have to cycle power on the Vybrid tower because the CMSIS-DAP debugging session hangs. Pressing reset on the CPU module doesn't help - I have to cycle power to the tower. Seems the K20 is getting hung up.

FYI.

[adiroot]

It turns out that CMSIS-DAP was actually running.  What threw me off what that

1) In SDA_INFO.HTM, it reports as being version 0.0

2) It is not easily found in device manager.  It appears as a HID-compliant device and an USB Input Device. 

     * In Win7, you can easily see it under Control Panel > Devices and Printers as OpenSDA CMSIS-DAP.

3) P&E's utilities do not find it

Thanks for replying Jack.  Is the debugging experience better with a hardware debugger like J-Link?

[jackblather]

Yes, I remember that getting the K20 to work reliably can be rather problematic. My SDA_INFO.HTM reports:

Board Name is: TWR-VF65GS
MicroBoot Kernel Version is: 1.04
Bootloader Version is: 1.08
Installed Application: PEMicro TWR-VF65GS10 Mass Storage App
Application Version is: 1.08

The CMSIS-DAP debugging experience under DS-5/Linux is not as good as using the J-Link hardware debugger under IAR/Windows. I use CMSIS-DAP under DS-5/Ubuntu and J-Link under IAR/Windows.

However, this might be the fault of the OS, Ubuntu. DS-5 crashes a lot, runs out of memory (despite having 3 Gig of RAM), is normally sluggish, and is VERY slow at times. So this makes me wonder about DS-5's debugging performance on Windows (DS-5 is also available for the Windows platform). In summary, this isn't exactly an apples-to-apples comparison since the two debugging methods are on different platforms. So CMSIS-DAP debugging on a Windows platform could be on par with a hardware debugger. I've been using DS-5 since about early November.

Also, as I reported in my earlier post (above), you'll see that the CMSIS-DAP firmware in the K20 frequently hangs and I have to power cycle the tower - pushing the reset button doesn't help.

In case you're wondering, we have to use Linux (and hence, DS-5) because we want to run embedded Linux (Timesys) on the Vybrid-A5 core. The development tools for embedded Linux run only on a Linux development platform. Oh well.

In contrast, my IAR installation (for another project) runs under Windows XP with 768 Meg RAM, is fast and reliable, J-Link debugging works great, and I don't recall this ever crashing.