[C6726] genAISfile problem

Dan,

I just noticed that this is a fairly old topic with no replies.  Are you still experiencing problems?

-Tommy

Tommy,

Thank you for the reply, I must say, I am not experiencing this problem at the moment, but it is something I still see every once in a while.  To resolve, I basically need to look at the code and rewrite it a little differently.  I have not figured out exactly what causes it, but I can recover.  Do you have any suggestions regarding this?

Dan,

Which device is this for?

-Tommy

C6726 processor.

I have seen this problem again, I cannot explain what is going on, but I do know how to fix it now.  It seems that in the GenAis process that if a section of code is split at a gpio pin boundry this error may pop up.  I basically added some dummy code to increase the overall code size and then the error will go away.

Well, this problem has occurred again.  It has taken a long time to figure it out, but I have discovered more information on the issue.

This is the GenAIS.ASM output when the error occurs:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Requesting CRC
;;;   Current CRC For This Section: 0xACFA328F
;;;   Number bytes to copy: 0x00002124
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    .word 0x58535902        ;Flash Address 0x90003FC0
    .word 0xACFA328F        ;Flash Address 0x90003FC4
    .word 0xFFFFDEC4        ;Flash Address 0x90003FC8
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;   Loading Section: .data
;;;   Current FLASH Address: 0x90003FCC
;;;   Section Size in Bytes: 0x000002A8
;;;   Section Type: 0x00000040
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;   PAGE 1, Current Page 0
;;;   Byte Count : 0x0000428C
;;;   Section Size in Bytes: 0x000002A8
;;;   Pin Cfg Size in bytes: 0x0000002C
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;   PAGE 1, Current Page 0
;;;   Byte Count : 0x00003FE4
;;;   Section Size in Bytes: 0x000002A8
;;;   Total Pin Cfg Size Needed: 0x0000002C
;;;   Pin Cfg Size For Next Page: 0x0000002C
;;;   Remainder on this page: 0x0000001C
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

So there is an error in the scripting system that it cannot recover from. 

So it is a sectioning problem, when the script generator chooses a chunk of code where the length pushes it near the limit, there is not enough space at the end of the page to issue the commands to switch to the next GPIO pin.  The scripting cannot recover from this issue.  The script should be more aware of the required space.  I have not programed in perl yet else I would take care of it myself.   So my previous answer is a work around but not a fix.  I was not able to get around it this time.

I do have another work around, this time I eliminated the CRC generation using the -crc 0 switch.  I do not know if this is a sure fix for all instances, but it did allow me to generate the needed code.  I did try the -crc 2, which generates a single crc at the end of the file, but this was incompatible with the modes I selected??

This now leaves me with some questions based on this workaround.  What exactly is the CRC function doing?  I am sure it is verifying that the eeprom to core transfer is loaded correctly?  If it was enabled and failed, does it attempt to reload the section or the page?  Do I have to worry about program load stability now that I am not using the function?