Jump to content

Recommended Posts

For now I am not going to get into the specifics (I am not sure exactly which uC I plan to use). I have a few questions to get everything clear in my head before I get to that point. I do know that I want to put new firmware on an external memory chip (EEPROM or FLASH).

 

Please follow my thought process and let me know where I am going wrong:

 

1. microcontroller powers up then jumps to bootloader

2. bootloader reads the external memory and checks if revision is greater than what is currently loaded in the uC

3. if this memory is, then the bootloader points to the memory location where the firmware is located and copies the new firmware to that memory location

4. at the end of the bootloader it points to the memory location where the firmware starts and then everything begins execution.

 

I am sure this is very vague and I do know there is a lot more to this than how I put it here. I have big questions on how to read the firmware from the external memory. I think reading the particular uC will help with this information. I know that some devices have EEPROM that might be useful to store the bootloader in, but some do not.

 

This is a lot of rambling but I was hoping that someone could help steer me in the right direction and possibly someone has some code examples of doing such a thing.

Share this post


Link to post
Share on other sites
For now I am not going to get into the specifics (I am not sure exactly which uC I plan to use). I have a few questions to get everything clear in my head before I get to that point. I do know that I want to put new firmware on an external memory chip (EEPROM or FLASH).

 

Please follow my thought process and let me know where I am going wrong:

 

1. microcontroller powers up then jumps to bootloader

2. bootloader reads the external memory and checks if revision is greater than what is currently loaded in the uC

3. if this memory is, then the bootloader points to the memory location where the firmware is located and copies the new firmware to that memory location

4. at the end of the bootloader it points to the memory location where the firmware starts and then everything begins execution.

 

I am sure this is very vague and I do know there is a lot more to this than how I put it here. I have big questions on how to read the firmware from the external memory. I think reading the particular uC will help with this information. I know that some devices have EEPROM that might be useful to store the bootloader in, but some do not.

 

This is a lot of rambling but I was hoping that someone could help steer me in the right direction and possibly someone has some code examples of doing such a thing.

 

 

Most bootloaders run with the new code on a PC and the micro processor checks for an attempt to download on its boot up. So what you are doing is not typical, should of course be possible. For most people the advantage of the bootloader is that they do not have to remove chip from its socket to program. You method would not seem to have that advantage.

 

Just some observations, not much help in getting your task done. Looking at some normal bootloader code for the pic could give you big blocks of code that would work.

 

Russ

Share this post


Link to post
Share on other sites

I understand that I did ramble a lot so I must have made myself unclear.

 

What I want to have is an EXTERNAL eeprom/flash chip. This means on a smart card or even a small PCB with a connector on it. This external board will contain the new firmware. I will need a bootloader on the microcontroller to see this external device and upload the new firmware from it onto the uC.

 

Like I said the eeprom/flash chip will not be a part of the PCB the microcontroller is on. If I was going to do that ISCP would work just fine.

 

Is that a little more clear?

Share this post


Link to post
Share on other sites
I understand that I did ramble a lot so I must have made myself unclear.

 

What I want to have is an EXTERNAL eeprom/flash chip. This means on a smart card or even a small PCB with a connector on it. This external board will contain the new firmware. I will need a bootloader on the microcontroller to see this external device and upload the new firmware from it onto the uC.

 

Like I said the eeprom/flash chip will not be a part of the PCB the microcontroller is on. If I was going to do that ISCP would work just fine.

 

Is that a little more clear?

 

I developed such a bootloader for the PIC24 family which bootloads from an SD/MMC card using the FAT file system. This bootloader was developed using Microchip's C30 compiler. I intended to port it to support the PIC18F family but it requires a lot of program memory to support the FAT file system and it therefore is really only viable for PIC18F processors that have a lot of program memory.

Share this post


Link to post
Share on other sites

asmallri,

 

I think I understand what you are trying to do. However, your question is unclear. You seem to have made a few statements rather than any real request for help. Here's my interpretation of what you may need.

 

As for which PIC to select, search the Microchip website. You will need one with the ability to self-write. As for reading the external eeprom/flash, most use the standard Serial Peripheral Interface (SPI), which is synchronous. You may find it useful to select a chip that has a Master Synchronous Serial Port (MSSP) built into it. Also, given that the PIC is going to modify itself, it will have to be flash based rather than OTP.

 

Your "bootloader" is not a bootloader in the traditional sense because it doesn't simply remove the hardware between the PC and the chip. You will probably have to write your own. In your main routine, the first thing you should do is see if the eeprom is attached. I'd suggest using a timer to create a time-out. If it is attached, use the MSSP to read the version number. If it is higher, collect the new program code into RAM and use the self-write feature to overwrite the program. Remember that you have to write a certain number of instructions all at one time because it's flash memory (the page size will be written somewhere in the self-write section of the PIC's datasheet).

 

Afterwords, make the PIC reset itself.

 

The hard part will be that the bootloader should probably not overwrite itself while it is executing. To do this, you will probably want to know exactly where it is in program memory. I'm not sure if it is possible to specify exactly where to put a routine using the BoostC linker. I don't believe it is currently possible, but I haven't looked for that information specifically. Search the forum for more information about that.

 

I hope this answers any questions you may have. Good luck.

 

- Bill

Share this post


Link to post
Share on other sites

I will add some more suggestions to the pot.

 

I think I read somewhere that all 18F chips are flash and therefore can write to their own program memory.

 

As said above, you can use a SD memory device with a FAT system on board but this is a large overhead on the bootloader as asmallri says.

 

A parallel external flash device is not practical due to the large pin count needed for the address and data lines. There are plenty of serial flash chips with an SPI interface built in. These come in 8 pin packages (SO8 or similar) and many are 3.3Vish so watch out if you are using a 5V system. SPI flash chips are usually paged into 256 byte blocks. The SPI interface has a small command set to allow you to specify which page to write to or read from etc.

 

The bootloader would be installed into your PIC starting from the reset vector (address 0000) up to say 0x07ff, which seems to be common although 2K may be a bit large for a simple bootloader. It hay have something to do with code page protection size. Some PICs have a bootloader section that can be protected from inadverant writes. Check the data sheet for the PIC use intend to use.

 

Page 0 of the flash chip may contain your product identification record. The first 8 bytes could be a set data pattern that the bootloader recognizes as a valid flash chip for your particular PIC application board. The rest of the record could contain software version, dat/time stamp, start/end addresses etc.

 

The rest of the pages from page 1 onwards will contain your program data. You may wish to create a record system within each 256 byte page giving: load address, record length, data block, CRC-16 for data integrity.

 

At start up your bootloader will try to read the first 8 bytes from page 0 to see if there if a device out there that it recognizes. If not, it checks if there is a an application program installed. If so run the application starting at say address 0x0800. If there is a recognizable flash device out there, read in the id record, check if it is newer than the installed application (if there is an installed application), read and flash the new application into the PIC, flag application installed and run it or wait for the flash card to be removed and reset to run the application.

 

Note: You cannot run code from EEPROM within the PIC as it is only 8 bits wide and not directly accessible by the CPU.

 

You will also need a programmer and PC application to take the BoostC hex file and write it to the mobile flash device.

 

I hope this adds to your collection of ideas.

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites

Thanks for the responses... they were helpful. I apologize that my initial post was so scatter-brained but I had a lot of thoughts and I am not good at getting those out in a structured manner!

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...