Helpful ReplyUSB Thumbdrive Bootloader (BETA 1)

Page: 123 > Showing page 1 of 3
Author
PIC32 Support
Junior Member
  • Total Posts : 81
  • Reward points : 0
  • Status: offline
2008/11/12 08:03:32 (permalink)
0

USB Thumbdrive Bootloader (BETA 1)

Looking for a simple way to update firmware on products in the field?  USB thumb drives are incredibly easy to use thus creating a simple and low-cost method for service personnel to update product already in use in the field.  This demo code enables users to boot load new firmware from a USB Thumbdrive. 

The attached demo code is provided as a beta release.   This demo code is intended for evaluation use only and not for use in production intent designs.  Modifications to the library are expected prior to the official release of version 1.0. 

1) This release targets Explorer 16 hardware platforms.   Future releases will support the PIC32 USB Starter Board (DM320003).  The migration effort is minimal for those who prefer to use the PIC32 USB Starter Board now.

2) Supports the PIC32MX4 series only.  A future release will support for PIC24F.

3) Start with the read_me.TXT file for details (NOTE: this is not the README.PDF located in the zip file)


Overview:
The boot loader provides a means of loading a properly-built application hex-file image from a USB Thumb Drive, programming it to Flash on the microcontroller and booting (launching) the application image.  To do this, the application image must be built using the "procdefs.ld" linker script (place it in the application's main project folder, but DO NOT include it in the project from within MPLAB).  After the application has been properly built, copy its hex file and name it image.hex to the root of the thumb drive.  You then press S4 on the Explorer 16 board while resetting the micro.  This will enter the boot loader mode, as indicated by LED D10 flashing.  Insert the thumb drive into the USB
Type-A receptacle and the boot loader will load and boot the application image.  If it is unable to find the file, D10 will flash rapidly to indicate an error.  To abort the load, press S4 a second time.
post edited by PIC32 Support - 2008/11/12 08:13:32
#1
remyar
New Member
  • Total Posts : 4
  • Reward points : 0
  • Joined: 2008/11/13 11:20:27
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2008/11/13 11:40:15 (permalink)
0
hello i'm french,
 
i desire to modifie your code for use with SDCard but it nor working the SD isn't initialised please help me. thank and sorry for my bad english !!
#2
jmag99
Super Member
  • Total Posts : 486
  • Reward points : 0
  • Joined: 2007/09/21 08:04:33
  • Location: RI, United States
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2008/11/18 09:03:11 (permalink)
0
Does this support thumb drives > 2GB?  I noticed that the file system app note says that it supports FAT32 but the app note for the existing thumb drive and embedded host says it only supports up to 2GB cards.
#3
jmag99
Super Member
  • Total Posts : 486
  • Reward points : 0
  • Joined: 2007/09/21 08:04:33
  • Location: RI, United States
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2008/11/18 11:19:04 (permalink)
0
Looks like FAT32 is a planned upgrade in the future according to the documentation.  Anyways, I tested the code and it works great.
#4
PIC32 Support
Junior Member
  • Total Posts : 81
  • Reward points : 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2008/12/12 16:20:12 (permalink)
0
A port of the open source FatFs filesystem has been posted in this forum.  It supports FAT12,16,32.   Click here to view it.
#5
gatnip
New Member
  • Total Posts : 1
  • Reward points : 0
  • Joined: 2008/12/17 11:01:21
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2008/12/17 11:09:40 (permalink)
0
Hello,
Saw this post and I have someone doing just this - however using a PIC24F device. Has this SW been released? Has it been ported for use with the 24F?
 
thanks
 
greg
#6
MNK1
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2008/12/15 02:31:13
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/01/20 06:58:05 (permalink)
0
Hello
Fantastic ! exactly what I need grin ... but for PIC24F [&:]
 
You wrote " 2) Supports the PIC32MX4 series onlyA future release will support for PIC24F. " 
 
Could you please tell me when you plan to support the PIC24F ?
 
thanks
 
Michel

 
#7
jmag99
Super Member
  • Total Posts : 486
  • Reward points : 0
  • Joined: 2007/09/21 08:04:33
  • Location: RI, United States
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/01/21 15:40:37 (permalink)
0
I think I have found a bug in this code.  I have a temporary fix until I can look into it further.

The bug occurs in the AddToBlock function when the record overlaps the start of a block.  The problem is that it doesn't take into account the valid index when defining the copy from position.  I have changed it to:


// Record overlaps start of block
pCopyFrom = &pRecord->data[BlockTargetStart - RecordTargetStart + pRecord->ValidIndex];


I think this could be reduced to just
 
pCopyFrom = &pRecord->data[pRecord->ValidIndex];


but have not tried it yet.  Can anyone else confirm this problem?
#8
PIC32 Support
Junior Member
  • Total Posts : 81
  • Reward points : 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/01/29 08:37:44 (permalink)
0
The “RecordTargetStart” value already accounts for the “pRecord->ValidIndex” value.  It is calculated a few lines earlier:

     // Calculate the start and end addresses for  record
    RecordTargetStart   = baseAddress + pRecord->LoadOffset + pRecord->ValidIndex;

The record-to-block-copy logic was designed to be completely general so that it would work correctly regardless of the relative sizes or positions of the record and the block.

If anybody is seeing an incorrect behavior, please post a description of it and provide information on how to reproduce it.
#9
jmag99
Super Member
  • Total Posts : 486
  • Reward points : 0
  • Joined: 2007/09/21 08:04:33
  • Location: RI, United States
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/01/30 06:05:43 (permalink)
0
I realize that RecordTargetStart is supposed to take into account the validindex, however there must be a bug somewhere along the line. If you give me an email address, I can send a hex file that will not program properly. When a text compare is done, you will see that priodically, when a hex record ends between the end of an old block and the start of a new one, it will copy several bytes into the start of the new block from the record that was already stored into the old block. My fix solves the problem (although there might be a better place to fix it).
#10
jtoebes
New Member
  • Total Posts : 18
  • Reward points : 0
  • Joined: 2009/06/02 06:09:39
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/07/20 19:11:16 (permalink)
0
Thank you very much for the sample code.  I've taken it and made extensive modifications to support FAT32 and run on the PIC32USB Starter Board, provide for LED debug status, get back a bit more memory and even handle verifiying that there is an image before attempting to launch it.  What's the appropriate way to provide these changes?
#11
amammes
Starting Member
  • Total Posts : 54
  • Reward points : 0
  • Joined: 2009/02/18 04:29:46
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/07/21 11:08:59 (permalink)
0
Are there any plans to support signed hex images? RSA could be implemented to sign the binaries.
#12
MrZANE
New Member
  • Total Posts : 17
  • Reward points : 0
  • Joined: 2007/10/17 00:26:55
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/08/05 16:17:24 (permalink)
0
Hi everyone.

jtoebes would it be possible for you to send your improved version of the bootloader to me?
My email is jimmy[DOT]pedersen[AT]mrzane.com
Thanks in advance

/Jimmy

#13
jtoebes
New Member
  • Total Posts : 18
  • Reward points : 0
  • Joined: 2009/06/02 06:09:39
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/08/08 21:55:49 (permalink)
0
The bug is definitely in there.  Here's a simple example of a .hex file which illustrates the bug:

:020000040000fa
:020000041d04d9
:10eff80000112233445566778899aabbccddeeff11


In Theory you should end up with:

  0x1d04eff8:  00112233
  0x1d04effc:  44556677
  0x1d04f000:  8899aabb
  0x1d04f004:  ccddeeff

But what you really get is

  0x1d04eff8:  00112233
  0x1d04effc:  44556677
  0x1d04f000:  00112233
  0x1d04f004:  44556677

The reason why this happens is that the routine AddToBlock in boot_load_hex.c doesn't correctly handle calculating the pCopyFrom address when you have a record that spans a page boundary.  There are a couple aways around it, but I decided to simply the code by moving the initialization of pCopyFrom and pCopyTo out of the if statement and then move the update of ValidIndex outside.  I also removed the decrement of RecordLength as it can introduce a bug IF by chance you happen to get an input record which is larger than a page size (unlikely since the longest record can only be 255 bytes since the length is stored in a byte and the size of a page is 4K.  I will package up the full project tomorrow and post it.


unsigned int AddToBlock( FLASH_BLOCK *pFlashBlock, RECORD_STRUCT *pRecord )
{
    unsigned long int   RecordTargetStart;
    unsigned long int   RecordTargetEnd;
    unsigned long int   BlockTargetStart;
    unsigned long int   BlockTargetEnd;
    unsigned long int   CopySize;
    unsigned char       iCopy;
    unsigned char      *pCopyFrom;
    unsigned char      *pCopyTo;
   
    // Calculate the start and end addresses for  record
    RecordTargetStart   = baseAddress + pRecord->LoadOffset + pRecord->ValidIndex;
    RecordTargetEnd     = baseAddress + pRecord->LoadOffset + pRecord->RecordLength;

    // Initialize the block address if block is new
    if ( pFlashBlock->blockState == BLOCK_STATE_NEW)
    {
        // Initialize block paramters
        pFlashBlock->address    = RecordTargetStart & BLOCK_ALIGNMENT_MASK;
        pFlashBlock->blockState = BLOCK_STATE_PARTIAL;

        // If the block has already been erased once, we've probably written data to it.
        if (TrackPageEraseTest(pFlashBlock->address))
        {
            // Fill the block buffer from Flash so that we can overlay new data on it and
            // mark it as not erased so we will erase it again before writing this block.
            memcpy(pFlashBlock->data, PA_TO_KVA1(pFlashBlock->address), FLASH_BLOCK_SIZE);
            TrackPageErase(pFlashBlock->address, PAGE_NOT_ERASED);
        }
    }

    // Calculate the start and end addresses for the block
    BlockTargetStart    = pFlashBlock->address;
    BlockTargetEnd      = pFlashBlock->address + FLASH_BLOCK_SIZE;
   
   
    // Determine the copy size and from/to addresses
    // (regardless of relative size of record and block buffers).

    pCopyFrom = &pRecord->data[pRecord->ValidIndex];
    pCopyTo   = &pFlashBlock->data[RecordTargetStart - BlockTargetStart];
 
    if (RecordTargetEnd <= BlockTargetStart)
    {
        // Record target is outside (before) block target
        pFlashBlock->blockState = BLOCK_STATE_READY;
        CopySize = 0;
    }
    else
    {
        if (RecordTargetStart <= BlockTargetStart)
        {
            // Record overlaps start of block
            if (RecordTargetEnd <= BlockTargetEnd)
            {
                // Record ends before block ends
                CopySize = RecordTargetEnd - BlockTargetStart;
            }
            else
            {
                // Block ends before record ends
                CopySize = FLASH_BLOCK_SIZE;
            }
        }
        else
        {
            if (RecordTargetStart < BlockTargetEnd)
            {
                // Record starts before block ends
 
                if (RecordTargetEnd <= BlockTargetEnd)
                {
                    // Record contained entirely within block
                    CopySize = RecordTargetEnd - RecordTargetStart;
                }
                else
                {
                    // Record overlaps end of block
                    CopySize = BlockTargetEnd - RecordTargetStart;
                }
            }
            else
            {
                // Record target is outside (after) block target
                pFlashBlock->blockState = BLOCK_STATE_READY;
                CopySize = 0;
            }
        }
    }
   
    // Skip past the bytes that we are copying
    pRecord->ValidIndex += CopySize;
   

    // Copy data from the record buffer to the block buffer
    for (iCopy=0; iCopy < CopySize; iCopy++)
    {
        pCopyTo[iCopy] = pCopyFrom[iCopy];
    }

    // Return TRUE of the block is ready to program to Flash
    if (pFlashBlock->blockState == BLOCK_STATE_READY)
    {
        return TRUE;
    }
   
    return FALSE;

} // AddToBlock

#14
jtoebes
New Member
  • Total Posts : 18
  • Reward points : 0
  • Joined: 2009/06/02 06:09:39
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/08/09 09:36:41 (permalink)
0
Hi All,  I've put together a version of my bootloader code and uploaded it to http://john.toebes.com/tetrix/bootloader.zip which incorporates all of the fixes I have found plus a couple from Dave Nadler. No promises that it will work for you, I would appreciate any feedback that people have one it or bugs that you find.  With the current compiler optins, I have gotten it down to 19,820 bytes with support for Fat32 and even status lights indicating what is happening.
  All Blinking indicates that no valid image has been found
  LED1 Solid, other two blinking indicates that a flash drive has been inserted but no image found.
  LED1 Solid, LED2 Blinking, LED3 Off - indicates that it is loading an image

Right now as compiled, the code looks for a file called samantha.hex for the project I am working on.  You might want to change that to your own image name.

Please let me know if you find any additional bugs.
#15
jtoebes
New Member
  • Total Posts : 18
  • Reward points : 0
  • Joined: 2009/06/02 06:09:39
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/08/10 21:19:26 (permalink)
4 (1)
Since I already had to deal with replacing the boot loader on a production module, I went ahead and created a Bootflasher which allows upgrading a bootloader.  Basically the way it works is it is a custom version of the boot loader which loads where the application would load.  It then looks for a new file bootload.hex which can not overlap the application space.  Once it successfully loads it, you will see a flashing pattern on the LEDS indicating that it is safe to power down.  You can find it at http://john.toebes.com/tetrix/bootflasher.zip 
#16
tvnpe
New Member
  • Total Posts : 21
  • Reward points : 0
  • Joined: 2008/05/09 12:29:48
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/08/12 19:36:23 (permalink)
0
Hi Guys,

I imported the precompiled hex file and program it to flash on the explorer16 with the usb pictail board and the PIC32 PIM. After power up I pressed and hold S4 and pressed the reset switch the LED D10 flashing to indicate that it is in boot loader mode.

I format a 2GB usb drive as FAT in windows xp, FAT=FAT16 correct?. I copied the image.hex from the included application folder to the usb drive. But when I plug the usb drive in to the usb pictail the LED D10 start to flash faster. According to the instruction when LED D10 flash rapidly mean an error.

Couple of you guys have yours working successfully, could you please help me out with my error? thanks.

Tuan
#17
friesen
Super Member
  • Total Posts : 1690
  • Reward points : 0
  • Joined: 2008/05/08 05:23:35
  • Location: Indiana, USA
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/09/08 18:59:45 (permalink)
0
There seems to be some issue with porting this to the 256L

It always hangs here - on the lw.  PageNumber is at 0ffff when this happens

226:                         flashPageStatus[PageNumber/32] &= ~( 1 << (PageNumber % 32) );
9D005858  24070001   addiu       a3,zero,1
9D00585C  00082442   srl         a0,t0,0x11
9D005860  00C74804   sllv        t1,a3,a2
9D00586C  00093027   nor         a2,zero,t1
9D005888  8C6D0000   lw          t5,0(v1)
9D00588C  01A66024   and         t4,t5,a2
9D005890  03E00008   jr          ra
9D005894  AC6C0000   sw          t4,0(v1)


Nevermind, it was an incorrect size of hex file.
post edited by friesen - 2009/09/09 08:48:07

Erik Friesen
#18
jtoebes
New Member
  • Total Posts : 18
  • Reward points : 0
  • Joined: 2009/06/02 06:09:39
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/09/10 07:15:03 (permalink)
0

ORIGINAL: tvnpe

Hi Guys,

I imported the precompiled hex file and program it to flash on the explorer16 with the usb pictail board and the PIC32 PIM. After power up I pressed and hold S4 and pressed the reset switch the LED D10 flashing to indicate that it is in boot loader mode.

I format a 2GB usb drive as FAT in windows xp, FAT=FAT16 correct?. I copied the image.hex from the included application folder to the usb drive. But when I plug the usb drive in to the usb pictail the LED D10 start to flash faster. According to the instruction when LED D10 flash rapidly mean an error.

Couple of you guys have yours working successfully, could you please help me out with my error? thanks.

Tuan

You are correct, but the bootloader that I have posted expects the bootloaded image to be called samantha.hex on the flash drive. You should change the value for BOOT_FILE_NAME code in boot_config.h to match what you want.


// Application Image File Name
#define BOOT_FILE_NAME "samantha.hex"


Hopefully this should help
-- John
#19
rubes99
New Member
  • Total Posts : 14
  • Reward points : 0
  • Joined: 2009/10/02 06:46:12
  • Location: 0
  • Status: offline
RE: USB Thumbdrive Bootloader (BETA 1) 2009/10/07 13:56:01 (permalink)
0
This question is to JTobes, I am currently working for a company trying to design a bootloader program and I was testing your design and for one I can't work on the workspace because of version control. And when I make my own project workspace and imort all the files there are some files that are not in your directory like "GenericTypeDefs.h" And when you say program the flash, what do you mean by that. Build and compile the workspace? Program to the microchip? Sorry I am new to the PIC32, just starting to learn some of the key details. I tried using the beta version of the USB bootloader and I am not sure if its working because I don't have any LED's light up.
#20
Page: 123 > Showing page 1 of 3
Jump to:
© 2017 APG vNext Commercial Version 4.5