cancel
Showing results for 
Search instead for 
Did you mean: 

_checksum16()

jdf25252
Associate II
Posted on October 09, 2013 at 23:02

I'm using Cosmic 4.3.6 compiler & have a project with greater then 32k code.  I need to checksum the flash at startup and periodically during runtime to satisfy UL60730.  My first project (about 12k code size) went well & everything was as I expected.With this one however, the checksumming blows up completely.  The descriptor table at __ckdesc__ is built using NEAR pointers, and the actual function f__checksum16 in cksum161.s fails miserably as it is expecting the descriptor to be in near memory.  Even if it was, all the pointers are truncated.  Of course the start address of 0x8080 is OK but the end address of 0x0651 instead of 0x10651 is completely wrong.

Hopefully I've done something wrong!  I'm not holding out much hope though.  Any ideas?

Thanks

jdf

3 REPLIES 3
luca239955_stm1_st
Senior II
Posted on October 10, 2013 at 09:37

Hello,

the descriptor should be built with 3 bytes adresses in your case: please try the latest compiler version and check if this is the case.

If you are using a full version (since you are above the 32k limit) you can contact me by email (luca   dot   ubiali at cosmic dot fr, remove the obvious) and I can help you check your project.

Regards.

jdf25252
Associate II
Posted on October 10, 2013 at 17:30

Luca

Thanks!  We let maintenance lapse a while back so I don't have that option right now.  We're planning to add another license but upgrading the other 2 is costly so management is resisting.

I looked at the release notes for 4.3.7 & it doesn't mention any fix for long pointers in the descriptor table. 

I have another project that is pressing, so I will be off this for 2/3 weeks.  I'll send an email when I can get back to this.

Again THANKS!!!!!

jdf

mtien888
Associate II
Posted on October 26, 2013 at 06:26

We have the same problem for compiler version 4.3.9.  _checksum16() fail if code exceed 32K (0x10000) boundary.

Even we still use free 32K compiler version, our program start at 0xa000 so that the code could exceed 0x10000.  

Michael Tien