p89c51rd2bn IAP problems

[Valent]

I have problems to reprogram the P89C51RD2BN in IAP mode. Some times the system is getting hang when it calls the Erase Code Block funtion of PGM_MTP. I have seen that this depents of SP (Stack Pointer) value.
I don't know the minimal Stack size needed by PGM_MTP calls, but no always with lower SP (stack  bigger) runs better.

A similar code is running ok in a P89C51RD2HBBD.

By other hand, I use FlashMagic to initial programming of the P89C51RD2BN but setting device=89C51RD2Hxx. The reason is because I need to generate checksums but like old format (8K and 16K blocks). I thouhg there was no problem due the compatibility. In fact the programming is ok. Am I rigth?

Can anybody help me, please?
Thanks,
   Valent

[Andy Ayre]

The hex file data is the same, so programming will work, but the flash blocks are differerent, so the commands to erase them are different. You can see all the differences by comparing the datasheets. I strongly recommend however that you always select the correct device in Flash Magic.

[Valent]

Thanks Andy,
but the ERASE 8K/16K CODE BLOCK command is also available with this 2nd generation of Rx2 devices. Although, in these devices is not necesary to repeated the ERASE STATUS BYTE & BOOT VECTOR for a six times.

Maybe, the best solution will be a FlasMagic with an option to select which kind of blocks are needed (4K or 8K/16K) to generate checksums. I think some people will be interesting with that due to the P89C51Rx2H is discontinued and must be replace with P89C51Rx2 in near future. In this case the code could be the same despite of the fact that FW checks the flash block checksums.

Valent

[Andy Ayre]

Thanks for your suggestion. We'll take a look and see what we can do.

[Todd]

I am using a P89C51RB2. I too have come across the bizarre behavior when doing a Erase Code Block funtion of PGM_MTP.

I also thought there was some correlation with the hang-up and the stack pointer. When I call the function in my Main() it works fine. When I call it in the actual spot I need to call it it hangs (SP=0x55 at this spot).

I really would appreciate some info regarding this. Does anyone have the source code for the BOOT_ROM? I read and disassembled 0xFC00-0xFFFF but it seems there are calls to hidden flash?

LFF4B:
PUSH   0E4H
ORL   0E4H,#080H
PUSH   PSW
ACALL   LF9AD
CJNE   R1,#000H,LFF5B
ACALL   LF9D9
AJMP   LFFD7

LFFF0: ;(AKA - PGM_MTP)
AJMP   LFF4B

Todd

[Ow Tong Peow]

Hi all,

   Came to here because I am now facing the same issue as you guys.  I am using P89C51RC2.  I am using the rx2iaplib.c .h supplied by esacademy.  During IAP_ERASE_BLOCK, the code never returns after call to PGM.

   Did some trial and error.  Found that for my case,  SP requires to be 0x46 or less to run reliably.  

   Once my SP reached 47 after compile, during IAP_ERASE_BLOCK goes to neverland and won't return to normal execution.

   I hope someone or Philips can advise on what the hell is happening during the IAP ERASE BLOCK.

    Luckily, due to this part shortage, my customer is intending to use Atmel part .  Hope Atmel don't have this issue.  Anyway, anyone faced problem using IAP in Atmel ? AT89C51RC2

[Jan Waclawek]

As far as I know Atmel did not publish the stack requirement for IAP, so you may face a similar problem.
Try to come to 8052.com forum with this problem.
Jan Waclawek



Post Edited (04-18-05 05:40)

[erikm]

Stack?  maybe

It is a fact that the ISP/IAP routines use certain RAM locations, somewhere it is posted (here?).

The idea is that "after programming follows a reset" and any deviation from that will get you where it hurts.

Erik

[Andy Ayre]

The Rx2IAP library is for the Rx2Hxx devices. If you are using an Rx2xx device then you need to compare the datasheets for differences in the IAP systems on these two families. You will then need to alter the IAP library to match the Rx2xx device.

Not sure about the stack pointer requirements for making IAP calls, but Philips tech support should be able to answer that.

[Ow Tong Peow]

Well, thanks for the guide.  Will read up on the IAP routines, basically just using rx2iaplib blindly (becos of the "rx2" name). LOL

But anyway, I will be switching over to At89C51RC2 today.  Gonna get the part in and first thing to do! IAP ... -_-!

But At89C51RC2 do not need to do erasing before write.... how wonderful, now my code can get even smaller.

[erikm]

But anyway, I will be switching over to At89C51RC2 today.

There are posts in other fora stating that the AT uses RAm and stack as well.

But At89C51RC2 do not need to do erasing before write....
itb does, it just does it automatically.  many have been caugtht by the fact that the Atmel chips with byte write still count page endurance for a byte wrire.

Erik

[Ow Tong Peow]

Dear Erik,

   Totally agreed that AT uses Ram and Stack.  I guess nobody will be able to advise on the safety margin of Stack to reserve.  My concern is only on erasing a block without screwing up normal operation.

   About Page endurance, I am not very sure.  Atmel is able to do 100k write cycles.  If I want to write 10 bytes to a page, is Atmel going to do

1) Read page to RAM, Erase page
2) Modify Byte1 in RAM, Write back
3) Read page to RAM, Erase page
4) Modify Byte2 in RAM, write back.
etc....

    I sure hope they are not stupid to do that. LOL.

    My feel is erasing an unused location, will not stress out that location.  Only erasing a used location will.   Please correct me if I am wrong, I don't do IC design.

[Jan Waclawek]

1. The manufacturer (author of the firmware) should be able to tell the stack and other resources requirement (e.g. other used memory, execution time). In fact, this IS a key information for IAP, so I think this information should be in the datasheet/IAP appnote. But, given the number of errors and unclean parts  in the IAP description of both manufacturers, I doubt they will publish this information soon. But you can try their support...
(btw. I cannot find the RD2H datasheet at Philips website...?)
2.In T/AT89C51Rx2, if you use the block write command, it erases/writes the FLASH only once. Note that you cannot write a block across 128B boundary. (I think it_is_ recommended to use block write for multibyte write in the datasheet).
3. Erasing often involves first programming all bits to 0 to achieve uniform charge in the floating gates before erasure. This is usually hidden for the user. If this is the case for Atmel, erasing unprogrammed bits/bytes does increase the wear.

Jan Waclawek

[erikm]

The manufacturer (author of the firmware) should be able to tell the stack and other resources requirement (e.g. other used memory, execution time).

If they did that they would not be able to modify it.

Just visualize:
you code a loader and publish: it is using 8 stack slots, RAM locations 38h, 47h and 66h.

Then you find a small bug and have to use one more RAM slot.  Result: evrybody that is using your loadre will have your GM.

Thus, it is not released, just "after load a reset must be performed"

Erik

[Jan Waclawek]

Sorry, what is "GM"?

And, the version of bootloader/IAP firmware can (should) be easily idetified; if it changes, the user can go to the manufacturers website and check the changelog (and/or errata). Ideally... :-)
With bootloaders in FLASH (upgradable - e.g. T89C51RD2, P89V51RD2 and probably others too) you can also "downgrade" if needed.

Jan Waclawek