Need some help creating an IAP app

jmullaney · ‎2008-12-26

Posted on December 26, 2008 at 23:44

#iap #bootloader #upsd3253

jdaniel · ‎2011-05-17

Posted on May 17, 2011 at 12:04

jhilory,

Sorry, but I'm afraid that my sample code wouldn't be of much use to you. The uPSD-based product I have is a daughterboard for a product my company makes. It is reprogrammed by another device via a DPRAM, so there's no PC utility to do the IAP.

ST's sample code, from what I remember, is complicated, but has alot of the basic components you could strip out to begin building your own app.

jsmith875 · ‎2011-05-17

Posted on May 17, 2011 at 12:04

phase426,

Thanks for your response. The prior postings regarding IAP, on this forum, have been a tremendous help. I think I understand enough, now, to begin implementing and testing. I'd still like to see how others might have modified ST's example code for running on a PC. I've been studying the source from the file 1112311177.zip downloaded from ST (dsniap\DK3X00_RS232_IAP_Demo_Windows_SW\source).

I found a NewPSDload.exe in a file, 1112380941.zip from ST, but it had no source. It was quite a bit larger than the dsniap one, above, and had a much more elaborate GUI interface. Does anyone know of any other source files for reprogramming through the PC serial port? I don't care about the elaborate GUI. In fact, I'd like to have something very simple, hardwired to my particular application.

Thanks,

jhilory

jdaniel · ‎2011-05-17

Posted on May 17, 2011 at 12:04

jhilory,

Something simple and hardwired to your application should be simple enough to just write from scratch. If the difficulty is that you haven't done serial port programming on the PC before, then that's a bridge you're going to have to cross with or without some source code at hand before you can write a decent app.

If you're going to put hex-file decoding on the target, then you really only need an application to send the hex file in ascii format with some sort of handshaking to indicate that records were received correctly. This should be pretty simple to accomplish.

-Phaze426

jsmith875 · ‎2011-05-17

Posted on May 17, 2011 at 12:04

Phaze,

You bring up an interesting possibility, which I had not considered. In the example IAP code supplied by ST, it appears that the main ''work'' is done by the PC software, with the target supplying only the most ''low-level'' routines for setting the VM and Page registers, and then reading/writing a string from/to a PC-specified beginning address. Their example includes the serial routines for the PC, already hardwired as to comm port, baudrate, etc.

If I move this main ''work'', previously done by the PC software, into the target code, I could then do a simple send of the HEX code pages to the target. These HEX pages, however, contain both the common code and the code for the current page, so the sending could take twice as long. The PC would still need to know something about the program structure in order to process the HEX page and send only the non-common code, thus reducing the IAP programming time.

Is my assumptions correct here, or am I not understanding how this all works?

I recall that icebell complained about the extra long IAP programming time, but was able to reduce it somewhat. Did she accomplish this by letting the PC skip sending the common part of each HEX ( *.H0[0-n] ) file?

jhilory

wek2 · ‎2011-05-17

Posted on May 17, 2011 at 12:04

There are two main issues communication-wise with ISP: the ISP entry method and the ''communication protocol''. You appear to have solved the first, so I'll deal only with the second, although both are related in some way.

''Sending a hexfile'' appears to be a pretty standard method for UART-ISP of a quite big ''subfamily'' of the 8051s, notably the RD2s. See for example

http://www.nxp.com/acrobat_download/applicationnotes/AN461_10.pdf

. Unfortunately, as this is only a defacto standard, there are variations among the manufacturers and even among individual chips of the same manufacturer - there is an overview on my pages

http://www.efton.sk/51comp/rd2comp.htm

.

The ''handshake'' is simple, too, the microcontroller simply echoes back every character, and at the end of line it appends an optional result and an endmark indicating success and/or failure (the ''readback'' is an exception, waiting for a CR after the line then dumping the required content).

The good thing about it is, that the intelhex is a widely accepted ascii file and can be ''downloaded'' using almost any terminal emulator (having specified a inter-line delay sufficient for the micro to ''burn'' the bytes received meantime). I was never concerned by it being slightly less ''effective'' than e.g. binary formats, as I was always able to run at sufficently high baudrate for the transfer (38k+), and never was so unpatient not to be able to wait for a couple of seconds longer... :)

But the best thing is, that there are already relatively comfortable tools available on the PC side for some of the RD2s - and you have to write the '51 side anyway, so why not writing it in a way which is ''compatible'' with an existing chip. I did the same, using the ''protocol'' of P89V51RD2 (not described in the abovementioned appnote) and now am ''abusing'' FlashMagic as a programming tool on the PC side.

Your mileage may vary, of course.

Oh, and for hexfile manipulation (e.g. cutting out a relevant part, but also much much more), check out

http://srecord.sourceforge.net/

.

Have fun!

Jan Waclawek

jsmith875 · ‎2011-05-17

Posted on May 17, 2011 at 12:04

wek1:

Thanks for your comments, suggestions, and links to information. I am almost sure that I am going to write an app for the PC that is hard-wired to do the IAP with my particular target. What I haven't quite finalized, however, is the memory layout on my target.

Anyone monitoring this thread:

The common code for each page will be in the lower 32K and the paged code will be in the upper 32K. Reprograming (with IAP) the banked code (upper 32K) seems rather straight-forward. But I am still wrestling with the details of how best to program the common area. I think I will have to map it into a page (unused for running code) in the upper 32K. I am assuming that I can then reprogram it in the different location by sending just the lower 32K of the common part of the HEX code, while adding 32K to the address in each line of the input HEX code.

Tentative memory map:

Code:

fs0 Common 0000h - 7fffh

fs1 Page0 8000h - ffffh

...

fs7 Page6 8000h - ffffh

Data:

rs0 Common 0000h - 3fffh only the lower 16k of RAM

csboot0 0000h - 1fffh Not accessible, overlaid by RAM

csboot1 2000h - 3fffh Not accessible, overlaid by RAM

csboot2 4000h - 5fffh XDATA

csboot3 6000h - 7fffh XDATA

csiop 7f00h - 7fffh

fs0 Page7 8000h - ffffh

Then, for IAP, csboot0 and csboot1 would be switched to code space, and would contain the IAP code.

Does this seem to be a feasible, logical way of doing things? Suggestions are welcomed!

jhilory

wek2 · ‎2011-05-17

Posted on May 17, 2011 at 12:04

Quote:

I am almost sure that I am going to write an app for the PC that is hard-wired to do the IAP with my particular target.

It's always good to get inspired having a look how others are doing the same... Especially if they (the 'RD2-makers) do it for quite a long time... Standards, even if they are only defacto, usually make sense and might contain a knowhow gathered during the years of use... The final choice is of course yours, this is no rocket science anyway... :)

Quote:

Does this seem to be a feasible, logical way of doing things?

Sounds absolutely perfect. I am surprised you don't already report on it's done successfully... :p

JW

isabel_benitez · ‎2011-05-17

Posted on May 17, 2011 at 12:04

Hello again,

I almost got it! I have been working a long time on it, I left the serial communications and I update de firmware with an sd memory card, the comm was a big trouble.

Now I can change the main program, but I cant make the same with the boot one.

My memory map is the one you taught me Phaze, and the secondary memory is as you say:

CSBOOT0:(0x0000-0x1FFF)||(0x8000-0x9FFF && PAGE==8)

CSBOOT1:(0x2000-0x3FFF)||(0xA000-0xBFFF && PAGE==8)

CSBOOT2:(0x4000-0x5FFF)||(0xC000-0xDFFF && PAGE==8)

CSBOOT3:(0x6000-0x7FFF)||(0xE000-0xFFFF && PAGE==8)

My main program execute and if you select th ''update boot option'' it goes to common area, in FS0 to excute it, then if I try to erase or to write in bank8, address 0x8000, nothing happens, I am doing something wrong, sure, but I donÂ´t know what.

Thank you for all the help and all your usefull lessons, I hadnt been able to do it without your advices.

Best Regards

Icebell

isabel_benitez · ‎2011-05-17

Posted on May 17, 2011 at 12:04

Sorry, but which is the difference betwen erase sector ande erase bulk?

Thanks again

Icebell

jsmith875 · ‎2011-05-17

Posted on May 17, 2011 at 12:04

Hello Icebell

I think when you switch your csbootx to page8,

CSBOOT0:(0x0000-0x1FFF)||(0x8000-0x9FFF && PAGE==8),

you must filter your original HEX code to select only the addresses below 0x8000, then add 0x8000 to each HEX code address, in order to program it in the new location.

Your original code will be at 0x0000 to 0x7fff, but the address of that same code when you move it to page 8 (for re-programming) will be 0x8000 to 0xffff. At the beginning of each line of code in the HEX file is the number of bytes represented by that line and the beginning address to program those bytes. You will need to add 0x8000 to the address in each line of the HEX code.