ARM 2.3.1 ElfFile.pokeUint32() changes?

Follow

Richard Webb

• March 21, 2013 20:56

I've been using the attached post-link javascript routine successfully with ARM 2.2 to run an ElfFile.crc32() on the linked object file. It places the CRC value and length into named initialized externally linked variables.

It works great. When the executable is run, it does a little __asm__ loop and calculates a matching CRC. Life is good.

However, in ARM 2.3.1.2013030700.17606, the javascript routine does not update the variables.

Running the same project under 2.2 (with a "clean" and "rebuild" between each compiler version switch) the variables are properly updated, the CRC is calculated by the run-time executable and it compares correctly to the ElfFile.crc32() result.

On 2.3.1, crc32.js does run and I see the expected results from the WScript.Echo() lines. The two variables, CrcLength and CrcValue, are reported from the script at the same locations (CrcLength @ 0x20000004 and CrcValue  @ 0x20000000) under 2.3.1 as under 2.2.

It looks like the problem is in ElfFile.pokeUint32(address, value, virtualNotPhysical). Under 2.2, leaving off the third parameter or setting it to true resulted in the variables being updated. Guessing that this was fixed in 2.3, since the docs state that virtualNotPhysical should have been set to false to get a physical address. However, none of the three possible values for virtualNotPhysical (blank, true, or false) seem to be effective in 2.3.1 in getting the value into the variable for the run-time image.

crc32.js

0

• 

  Jon Elliott

  • March 22, 2013 15:16

  Hi Richard,

  I've just tried your script here using the 2.3.1 release and it appears to be working with no problem for me, after adding CrcLength and CrcValue constants to a program, I can see that they have been modified correctly in the updated .elf file.

  Could you attach a complete project that demonstrates the problem?

  Regards,

  Jon

  0

  Comment actions Permalink
• 

  Richard Webb

  • March 22, 2013 16:19

  I sent it up over in the request queue.

  I'll also give it a try with just a minimal "blinkie" project to see if I can figure out what I may be doing that's causing the different behavior.

  0

  Comment actions Permalink
• 

  Richard Webb

  • March 23, 2013 22:25

  Resolved.

  The fix in this case was to move the invocation of the javascript routine from User Build Step Options -> Post-Link Command to ...-> Link Patch Command.

  The precise reason for the necessity of the change remains a mystery, but I'm good with that.. A certain amount of "do it this way because it works" is quite acceptable, as long as the "this way" is ultimately found. And it was an interesting hunt.

  0

  Comment actions Permalink

Please sign in to leave a comment.