Vybrid USB Loading Utility

[rod_k]

Is there a Windows-based utility program for USB (Serial Loader) that can be used to download a boot image programming application (for on-board NAND Flash) into the on-chip RAM?   The app would handshake with the PC to obtain a boot image for the NAND device (parallel, not QSPI), then program the NAND, so the next time we reset, the image is loaded from NAND.  We have the jumpers on our Vybrid demo board set to boot from NAND Flash, but there is no boot image in the device.  We believe that (based on the documentation, Figure 19-1 of the Vybrid RM), the high-level on-chip Boot ROM flow will drop into "Download and Authenticate Image Using USB/UART" mode.  We are wondering if this serial loader/programmer application exists already from FSL, or do we have to create our own.  Thanks in advance...

[rodrigomendes]

Hi all,

Has Mfg_Tool been released?

Thanks in advance

Rodrigo Mendes

[RossMcLuckie]

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xx&fpsp=1&tab=Design_Tools_Tab

In the programmers section.

Ross

[paweltryfon]

How is the progress on MFG_Tool for Vybrid going?

Btw, I almost succeeded in developing my own tool loading program image to memory. Sending data to device using SDP WRITE_FILE command worked fine. However, after doing JUMP_ADDRESS command it doesn't execute correctly and execution goes back to boot ROM. Any ideas how to debug it?
I was using DS-5 for the time being so I was able to see that program was actually loaded to memory where I wanted.

Many thanks!
Pawel

[RossMcLuckie]

The latest information on the Mfg_Tool is we expect to have an official release end or March, early April, depending how well testing goes. This will be the beta version, plus support for NAND on the Tower board.

As for your own version, are you maintaining the 16 byte (17 including report ID) SDP format, most of the fields are not relevant for the JUMP_ADDRESS command so you can put whatever data you want, but suspect they will still be needed, can simply be all 0's.

Do you see a Report3 back from the device, unless you see this then you are not successfully sending a correctly formatted JUMP_ADDRESS SDP.

Regards

Ross

[paweltryfon]

Thank you for the update Ross.

I do maintain 16+1 SDP format and all irrelevant bits are set to 0. I get Report3 back from the device and I do not get Report4 which according to the Vybrid manual is the sign that jump was successful.

It occured to me that I might be using illegal part of memory. My program is stored starting from 0x3f000000 address which is mapped to OCRAM-SysRAM0, it might be the case that it's used by boot rom so I overwrite its data structures. What are legal address ranges to store program binary loaded via Serial Downloader?

Many thanks,
Pawel

[billpringlemeir]

Your image must be formatted with IVT, DCD, etc.  It is not a straight code image/routine address.  The same code executes for engineering/production so where the HAB is validating an image all the same structure/code must be present.  You can use one of the bootable MQX Cortex-A5 projects for instance.

[paweltryfon]

Bill, Ross,

Thanks guys for your valuable help! I've got it working now.

Best regards,
Pawel Tryfon

[RossMcLuckie]

Pawel,

That's great news, if you get a chance it would be good if you could summarise what you did/changed for the benefit of others.

Thanks

Ross

[paweltryfon]

Sure.

Few observations that I think weren't (clearly) stated in the Vybrid RM:
1. SDP commands fields COUNT and ADDRESS should be big-endian
2. The manual is inconsistent with regard to FORMAT field in WRITE_FILE command, in my case I've set it to 0x20, I don't remember if it works without it.
3. I was using OCRAM - SysRAM0 starting from (0x3f000000) for my program image. IVT offset when using Serial Downloader is not defined, so at first I tried offset 0. In this case my smaller test program didn't work at all, but the second one worked, but part of its output was corrupted. There were no issues when I was using IVT offset 1K the same as for a SD card. Conclusion from this one is that bootloader seemed to use some part of program image memory before IVT (0x3f000000-0x3f000400), not sure if it's always this part of memory or always 1K before IVT or something else.

4. When cooking up program image take into account that there might be a bug in program image size arithmetic in the bootloader. To work it around set program image size in BOOT DATA section to N, where N = k * 256 >= actual program image size, in words program image size needs to be set to at least smallest multiple of 256 that is equal or larger than actual program image size. Example: if real program image is 0x153c or 0x15ff set it to 0x1600 or higher otherwise it might not work. I noticed it when writing a tool for creating program images for an SD card. In the case of Serial Downloader it might not make the difference, because an image is already in memory.

For USB communication I was using libusb and I was working with .axf files produced by armcc with binutils (readelf, objdump and objcopy) that came with DS-5 IDE.

Best regards,
Pawel Tryfon

[billpringlemeir]

I think imximage.c gives some more info on the oddities of HAB alignment.  They seem to align the image to 4k no matter what.  It is also very instructive to get the bootable MQX project in 'mqx/examples/bootloader_vybrid', which can be used as a USB download; it is already formatted properly.  You can include a USB stack within MQX and this can be the secondary protocol (ATK, etc) which can handle commands to program NAND flash, etc on your board.  MQX is free to use on a Freescale device and I think everyone with a Vybrid chip has one...

This thread on the community has information on another solution.

[paweltryfon]

Thanks Bill, it starts to make sense. Few days ago I wrote a tool that creates program image for SD card from any .axf file so I have most of program image topic worked out.
So assuming that I loaded my program image starting from 0x3f000000, ivt is at 0x3f000400 and code entry address is 0x3f000800, what should be the value of ADDRESS field of JUMP_ADDRESS SDP command? I assumed here that ivt offset is the same as for a SD. What should be ivt offset when booting from USB using Serial Downloader?

Many thanks in advance,
Pawel

[billpringlemeir]

Sorry, I guess you already ran through the permutations.  The imxheader.h in u-boot has the standard offset as 0x400.  This allows a little bit of code to place some 'reset' handler as sometimes the beginning of the image is the reset.  You can also put the IVT reset pointer to point to the initial 0x0 address.  This lets an image work with u-boot or via USB;  I believe this is the reason the offset exits.  The ONE_NAND and NOR have different offsets due to device issues (sector size, ID read location, etc); or that is my belief.

[billpringlemeir]

It is most likely a swapping issue, the JUMP_ADDRESS seems to be big endian.  The command sets use a mixture of both endian-ness and I don't think what endian things are is documented.

         u_char hid_report[64];

         memset(hid_report,0,sizeof(hid_report));

        // report code

         hid_report[0] = 1;

        // command type

         hid_report[1] = 0x0B;

         hid_report[2] = 0x0B;

        // address is big-endian

         hid_report[3] = (address >> 24) & 0xFF;

         hid_report[4] = (address >> 16) & 0xFF;;

         hid_report[5] = (address >>  8) & 0xFF;;

         hid_report[6] =  address & 0xFF;

[paweltryfon]

Thank you Bill.

I tried both big and little endian for ADDRESS field and you are right it should be big endian. I still don't see my program starting. Is there any initialization/register settings required I am not aware of?

I am able to see that my program loaded correctly and when I jump to the entry address from DS-5 debugger it works fine. It seems that I just have some issue with doing JUMP_ADDRESS command. Any hints regarding how to debug this will be much appreciated.

Many thanks,
Pawel

[billpringlemeir]

It is easy enough to use hidapi to get communications working with the Vybrid in Serial-USB.  HidAPI supports Windows, Mac, FreeBSD and Linux.  Most other HAB serial loader documentation is the same on the Vybrid.   For example, I am migrating IMX25 code and the command structure is identical with a smaller allowed peripherals in the DCD.  See chapter 19.8 of the Vybrid manual for more on the Serial-USB protocol.

Here is a hacked up version of hidtest.c,

/*******************************************************

Alan Ott - Signal 11 Software

Copyright 2009, All Rights Reserved.

This contents of this file may be used by anyone

for any reason without any conditions and may be

used as a starting point for your own applications

which use HIDAPI.

********************************************************/

#include <stdio.h>

#include <wchar.h>

#include <string.h>

#include <stdlib.h>

#include "hidapi.h"

// Headers needed for sleeping.

#include <unistd.h>

int main(int argc, char* argv[])

{

    int res;

    unsigned char buf[256];

    #define MAX_STR 255

    wchar_t wstr[MAX_STR];

    hid_device *handle;

    int i;

    if (hid_init())

        return -1;

    // Open the device using the VID, PID,

    handle = hid_open(0x15a2, 0x6a, NULL); /* Vybrid */

    if (!handle) {

        printf("unable to open device\n");

         return 1;

    }

    // Read the Manufacturer String

    wstr[0] = 0x0000;

    res = hid_get_manufacturer_string(handle, wstr, MAX_STR);

    if (res < 0)

        printf("Unable to read manufacturer string\n");

    printf("Manufacturer String: %ls\n", wstr);

    // Read the Product String

    wstr[0] = 0x0000;

    res = hid_get_product_string(handle, wstr, MAX_STR);

    if (res < 0)

        printf("Unable to read product string\n");

    printf("Product String: %ls\n", wstr);

    // Read the Serial Number String

    wstr[0] = 0x0000;

    res = hid_get_serial_number_string(handle, wstr, MAX_STR);

    if (res < 0)

        printf("Unable to read serial number string\n");

    printf("Serial Number String: (%d) %ls", wstr[0], wstr);

    printf("\n");

    // Read Indexed String 1

    wstr[0] = 0x0000;

    res = hid_get_indexed_string(handle, 1, wstr, MAX_STR);

    if (res < 0)

        printf("Unable to read indexed string 1\n");

    printf("Indexed String 1: %ls\n", wstr);

    // Set the hid_read() function to be non-blocking.

    hid_set_nonblocking(handle, 1);

    memset(buf,0,sizeof(buf));

    // ERROR_STATUS (cmd 0x0505). The first byte is the report number (0x1).

    buf[0] = 1; /* report 1 */

    buf[1] = 5; /* ERROR_STATUS */

    buf[2] = 5;

    res = hid_write(handle, buf, 17);

    if (res < 0) {

        printf("Unable to write()\n");

        printf("Error: %ls\n", hid_error(handle));

    }

    // Report 3 - engineering/production

    res = 0;

    while (res == 0) {

        res = hid_read(handle, buf, sizeof(buf));

        if (res == 0)

            printf("waiting...\n");

        if (res < 0)

            printf("Unable to read()\n");

        usleep(500*1000);

    }

    printf("Data read:\n   ");

    // Print out the returned buffer.

    for (i = 0; i < res; i++)

        printf("%02hhx ", buf[i]);

    printf("\n");

    // Report 4 - data returned to 0x0505 (ERROR_STATUS).

    res = 0;

    while (res == 0) {

        res = hid_read(handle, buf, sizeof(buf));

        if (res == 0)

            printf("waiting...\n");

        if (res < 0)

            printf("Unable to read()\n");

            usleep(500*1000);

    }

    printf("Data read:\n   ");

    // Print out the returned buffer.

    for (i = 0; i < res; i++)

        printf("%02hhx ", buf[i]);

    printf("\n");

    hid_close(handle);

    /* Free static HIDAPI objects. */

    hid_exit();

    return 0;

}

[Chandu_Allgo]

Hi

When MFG_Tool will be ready for Vybrid family..

Regards,

Chandrashekhar.v

[RossMcLuckie]

The alpha and beta releases have been posted on the Vybrid extranet site, hopefully this should signal a public release early in the new year.

Ross

[xtrontec]

Just wondering if there is any new information about when this utility / tool will be ready / released.

Thanks.

[RossMcLuckie]

At this time I have no further updates to give on this, I believe there are plans to review what is next for the Vybrid version of the Mfg_tool, one possibilty is the current beta version will become the final production release version, any update to the situation will be added here.

Thanks

Ross

[ioseph_martinez]

Hello All, I was checking this internally, sorry for not posting a follow up.

RossMcLuckie this is what I mentioned on our call, could you help providing your thoughts?

Thanks,

Ioseph