making a flash image [was: m68k/efi332 pb in boot_card() in flash]

[Ian Caddy]

Hi,

This is just a guess, but it sounds like the sort of problem where your 
initialised data section is not being copied from Flash to RAM or it is 
being linked directly into RAM and so is not copied into your target on 
programming.

With the CPU32 processors, three is no hardware breakpoint for debugging 
in flash, but what we used to do is where you want to stop, hard code in 
a asm(jsr 0xblahblah) where blahblah is a known address in RAM, then 
once you have loaded your code, make sure you handcode an RTS at that 
ram location.  You can now put a breakpoint on on that RAM location and 
your code will stop and you can now single step into the problem area.

It is very cumbersome but it is one of the only ways to get debugging in 
flash, until you get to newer processors that have a hardware breakpoint 
such as the Coldfire processors.

I hope this helps,

Ian Caddy


Jean-Baptiste Maillet wrote:
> Hello,
> 
> Thanks to Aaron and Matt for their suggestions.
> I think there's something fundamental I did not understood in the 
> process of making a flash image.
> 
> (summary: I use a modified efi332 bsp (68332). The modifications are 
> limited to chip
> select + linker script. It runs fine in ram. When in flash, it looks 
> like I don't go beyond the line:
> bsp_isr_level = rtems_initialize_executive_early( &BSP_Configuration, 
> &Cpu_table );
> ...in boot_card().
> I did some trials with the mrm332 bsp instead of efi332 (sources from 
> last snapshot), close enough from efi332 and got exactly the same result.)
> 
> In order to prepare a flash image:
> 
> 1 - in /opt/rtems/CPU/BSP/lib, I backup the linkcmds and copy the 
> linkcmds_ROM to linkcmds or pass an option to ld in the Makefile
> 
> 2 - I rebuild my app
> 
> Then the image has code in rom but data (which code address refers to) 
> and bss are in ram, as can be seen by a rtems-CPU-objdump -h
> So:
> 3 - I issue an CPU-rtems-objcopy --adjust-section-vma .data=XXXX 
> myapp.nxe myapp.flash
> With XXXX being the size of the text. As I understood from the BSP & 
> device driver manual, section 4-5. This does not work because (I think) 
> there's an offset before the text for reset and vbr vector + EVT. I can 
> see that BSP_Configuration is wrong (all ffffffff).
> 
> 4 - I then use a CPU-rtems-objcopy --adjust-section-vma .data=YYYY 
> myapp.nxe myapp.flash
> With YYYY being size of text+offset. Better now: BSP_Configuration or 
> Cpu_Table are OK for instance.
> 
> 5 - Then I think that it's cumbersome to calculate this size+offset 
> thing for each app, script or not, and decide to be smarter than I'm for 
> real. In the linker script, I declare a .data_rom section wich goes in 
> rom, with the same content that the .data section. I of course change 
> the symbols (_data_start_rom instead of _data_start etc). I let the 
> regular .data section so that the code refer to. I declare the new 
> symbols as extern in the code and instead of copying from _etext, I copy 
> from _data_start_rom. Of course it will be a problem for ram linking 
> (symbol undefined), but my pb is flash right now. It still works the 
> same, BSP_Configuration is OK etc. But still crash.
> 
> 6 - then I see that after data copying, the efi332 BSP copy the EVT in 
> the beginning of ram, silently overwriting the beginning of my data. I 
> don't see an easy way of controlling that and...
> 
> 7 - ... gave a try with a quick port from the mrm332 BSP just for a try, 
> and followed the same steps 3-4-5. The EVT goes after the data in ram if 
> I saw correctly, so that should be better, but nope.
> 
> Same symptoms from 2 different BSP: there must be something I missed 
> completly in the process of going from an app build using a linkcms_ROM 
> script to an actual flash image. ld scripts, use of objdump and objcopy, 
> all together?
> 
> I would be glad if someone please explained me how terribly wrong I am.