where to start with In Application programming

[Xarion]

Hey guys

I've recenlty had to move to a S08QE device beacuse the 8051 core I am using is becomming obsoleted. I would like update firmware over the air, I have 64KB of eeprom that i can use to temporarily store my new code.

How would you recommend I reflash my device? Store and run my reflashing proceedure in RAM then read the S19 (stored in the eeprom) and write it to flash?

I have seen quite a few references to the doonstack procedure but I am a bit lost as I am not really familiar with it or the freescale  ASM code.

How does the doonstack work? How can I use it to reflash my device? Would I have to code my reflash procedure have to check at the checksum etc in the S19 before writing or does the doonstack include this perhaps?

Thanks

[bigmac]

Hello,

---

Xarion wrote:

I've recenlty had to move to a S08QE device beacuse the 8051 core I am using is becomming obsoleted. I would like update firmware over the air, I have 64KB of eeprom that i can use to temporarily store my new code.

---

I am not exactly sure what you wish to achieve?  The expression "over the air" to me means something different than using an external SPI type EEPROM to provide new application code.

The usual method is to use a flash resident, bootloader program to communicate with the MCU via SCI module.  The bootloader is capable of erasing and re-programming the application flash area, usually situated immediately below the bootloader code.  There are many references to this type of bootloader within this forum.  The bootloader code needs to be programmed using a Multilink Interface, or similar, or a demo board that has inbuilt programming capability.

If you wish to use an external serial EEPROM this should also be feasible.  A couple of possibilities come to mind.

You might adapt the "standard" serial bootloader to directly read from the EEPROM device, rather than use the SCI.  If the presence of an EEPROM could not be detected, the bootloader would initiate the application, othwise it would re-program the application code.

Another possibility might be to have the majority of the bootloader code also located on the EEPROM, and to then temporarily load this code to RAM, and run the bootloader code from there.  This is what you seemed to be alluding?  Of course, this method would require some flash-based, rudimentary loader code that would be the destination of the reset vector, and would also provide redirection to the application program of all the other interrupt vectors (as does the serial bootloader).

During the erase process for a flash sector, or the programming of a flash byte, flash memory becomes inaccessible.  The code that executes under this circumstance needs to execute from RAM.  This function (or routine) is kept to minimal size, and would normally be placed on the stack, and executed from there (i.e. doonstack), or alternatively could occupy a fixed position in RAM, maybe at the very bottom of the stack.  My personal preference is the second method because it has simpler, more understandable code.

However, should the bootloader operate from RAM based code, as for the second scenario above, the flash routines would become simpler without the need to tranfer execution from flash to RAM, and you would certainly not need the complex doonstack code.

When using the SPI module as a master, as you would with SPI type EEPROM, it is quite unnecessary to use interrupts under most circumstances.  The only justification would be with a very slow SPI clock rate, which would not apply for your application.  The interrupt capability is more useful for a SPI slave application.

Regards,

Mac

[Xarion]

Hi Rocco and Bigmac

Thank-you for the valuable information. I didnt quite elaborate my situation, by over the air i mean that my application is GSM-based and i will be able to download the S19 file to the external EEPROM. (not sure if the S19 file is the easiest to use?)

I think what I'm going to look at is the doonstack and get to terms with the ASM of freescale as i will have to write the SPI code (to read from the external EEPROM) then use the FlashProg routines from doonstack.

I just failing to see at what point what directives are used to store the doonstack functions in RAM. are .asm files automatically executed first on reset?

Thanks again!

[bigmac]

Hello,

I gather that you are using a GSM modem to receive the S19 data and store in EEPROM, and then require to transfer the the EEPROM data to the application flash block.  I do not see why you need the intermediate EEPROM storage, rather than directly program the flash memory using the incoming S19 data.  This is the usual arrangement for a bootloader.

The doonstack function (sub-routine) does a simple task.  It loads the small sub-routine 'SpSub' into the stack memory, executes the sub-routine, and then adjusts the stack pointer to recover the stack memory used.  It does nothing else.

The doonstack function is called within the flash sector erase and byte programming functions.

As I mentioned previously, the same functionality can be achieved in a simpler manner, by using a fixed location in RAM for the RAM based function.  Keep in mind that the bootloader variables and  stack, and the application variables and stack, do not simultaneously exist,  The amount of RAM usage by the bootloader has no affect on the application code.

Regards,

Mac

[bigmac]

Hello,

I have just realised that, if you intend using the QE128 device containing paged flash and MMU module,  the flash programming and erase functions will differ from the code for other devices where all flash memory is directly accessible.  My understanding is that the LAP registers need to be used in order to address all of the flash memory.

Regards,

Mac

[tonyp]

Actually, the same routines can be used with paged memory.  No need to go through LAP.  Just need to move the correct page to the foreground before programming it.

[bigmac]

Hello Tony,

My point was that the "standard" flash functions would require to be altered to suit a paged memory device.

Yes, the PPAGE value would need to be calculated, and the 14-bit low order address would need to be offset into the paging window.  Obviously additional flash programming code is required to achieve this.

If we assume that the bootloader input data consists of records from a S19 file, and for a paged memory device the data would be within S2 records (3-byte address), or S3 records (4-byte address), in lieu of the usual S1 records.  The use of the LAP register may actually be simpler, with direct entry of the start address for each record.  Auto increment of the address might also prove useful.

The device reference manual also happens to mention that the most frequently used purpose of writing via the LAP is during flash programming.

Regards,

Mac

[tonyp]

Well, OK, but you're making some assumptions that aren't necessary.

(I'm making my own assumptions.  Let's say we're dealing with a bootloader that needs to load S records into the full memory of a QE128 device.)

The S-record loader I condider a different logical module, so whatever (minor) address manipulation happens in there is completely outside the Flash module.  My bootloader (for QE128) works like this:

* First, all application memory pages are cleared to be ready for the new code.

* Anytime a new S-record begins (regardless of type, S1, S2, ...) PPAGE is set to the default value (2).  That way, $8000-$BFFF found in S1 records will end up where they should.

* When processing S2 records, the extra address byte is the page address.  Once an S2 record is detected (instead of the usual S1), the extra address byte is immediately programmed into PPAGE.  This brings that page into the Flash window (until the following S-record is read).

* The rest of the S-record is processed as usual - 2 address bytes (must be in window range, anyway) followed by data.  All paged code/data will go into the page window.  No address translation of any kind.  Using the LAP method would require an extra address translation step, so this method is even simpler.

No Flash code needs to be modified from the one used with non-paged devices.  I use the exact same Flash code with several variants, the QE32, the QG8, and the QE128, etc.

The only difference from non-paged device is not in the Flash code but in the S-record loader to deal with S2 records, which initialize the PPAGE to a non-default value.  I have been doing this for years with the QE128 and it works great.

I also have applications that use the extra pages for pure data.  So far, I have never had to use the LAP method for any reason.  (Note: I keep all my read/write routines outside of the page window -- another assumption.)  The only reason to use LAP (in my understanding) is when code running from one page needs to access data (not code, for which there is CALL/RTC) in another page.  But, so far, I've dealt with it by avoiding this possibility in my code/data organization.

[bigmac]

Hello Tony,

---

tonyp wrote:

The S-record loader I condider a different logical module, so whatever (minor) address manipulation happens in there is completely outside the Flash module.

---

I have a problem with this.  If the flash programming function requires to program a byte value to a specific address, the full address needs to be passed to the function, in one form or another, so that there is no reliance on having a correct variable setting from within another module.  The address format should be evident from the programming function prototype.  The absolute address might be passed as a 32-bit (dword) value, or alternatively as ppage value (0-7) plus offset value (0x0000-0x3FFF).  The first method would seem more straight forward IMHO.

---

tonyp wrote:

* When processing S2 records, the extra address byte is the page address.  Once an S2 record is detected (instead of the usual S1), the extra address byte is immediately programmed into PPAGE.  This brings that page into the Flash window (until the following S-record is read).

* The rest of the S-record is processed as usual - 2 address bytes (must be in window range, anyway) followed by data.

---

According to the  manual for the CW burner, with Sx (default) setting, S2 records will be generated when the highest address within a program exceeds 0x00FFFF.  The three-byte address associated with each S2 record I would expect to be the absolute address, with the following available range for a device with 128K flash capacity.

0x000000

...

0x00FFFF

0x010000

...

0x01FFFF

If this is so, the "extra" byte does therefore not represent the PPAGE value, nor do the other two bytes represent the offset value.  Since S-records are applicable to a wide range of MCUs with different extended addressing schemes, it does not make any sense for an address to be other than an absolute address.

Regards,

Mac

[tonyp]

Hello Mac,

I'm afraid you're still making some assumptions that aren't true for everyone.  (And I hope I'm not the only exception here!)

For one thing I do not use CW.  And, I was talking about how my own bootloader interprets S19 files.

Besides, the P&E programmers I normally use follow (almost) the same S-record scheme I'm talking about (with one minor difference -- they assume $8000-$BFFF even in S1 records to be page 0), where the extra byte in S2 records is the PPAGE value.

I could also produce S19 files with linear addressing format, if a different programming tool requires that.  But, by default I find the PPAGE:ADDRESS format more convenient.

As for the Flash function requiring a 'full address', again it's a matter of perspective.  I look at an MCU with a native 64K address space as having only 16 bit addresses.  Programming any swappable memory outside the 64K means I need to use a wrapper function that first sets the correct PPAGE bringing that page into view and then calls the normal Flash function with only the 16-bit address within the page window.  (In my view, the wrapper function is needed regardless of the page issue -- even for non-paged MCUs -- because when dealing with data, you must somehow make sure the pointer passed into the function that, say, reads/writes a table, is within the expected data limits, ie., start/end of table.)  There's more than one way to deal with these issues.  And there is no one correct way, right?

Anyway, that's how I've been dealing with these issues, and it works great for me, both logically and physically!

[TurboBob]

Hi,

The doonstack came from the original freescale app notes as far as I know.  The flash routines must be run out of ram,  and running from the stack was an easy way to do it without tying up ram resources.

As it turns out,  only a small portion of the routine must be run from ram,  and this thread:  https://community.freescale.com/thread/39152  uses that fact to simplify the flash routines.

I use them in some HCS08AW  and JM projects with no issues.

Assuming that you don't need the data encrypted when it is in the eeprom,  then I would decode it and store it as a straight binary,  and then have a routine that runs in a portion of flash that doesn't get replaced do the updating.

I am in the same situation with some 8051 chips getting discontinued,  I started a thread on here about this very issue.  There are other suppliers picking up where NXP is killing parts this year.

Bob

[Xarion]

Found a great app note to do with doonstack http://cache.freescale.com/files/microcontrollers/doc/app_note/AN3942.pdf?fpsp=1 (for anyone starting with this)

Next step

How am i going to write my interrupt service routines for SPI in RAM? I'll need them to get the data from the external EEPROM?

[rocco]

Hi Xarion,

---

Xarion wrote:

How am i going to write my interrupt service routines for SPI in RAM?

---

You cannot use interrupts while programming the flash. The interrupt vectors reside in flash, and the flash is not accessible during programming or erasing. You will need to run the SPI in polled mode for programming.