Hi,
The context is ARM TMS570LC4357 MCU GNU cross-compiler on C, .elf file, 2 projects, second project is RAM loaded code
My ARM project code loads in RAM another ARM sub-project. The code is normally working but now I have a bug to locate and solve.
The problem: After loading the code in RAM, I call the RAM-based entry function of this code but the Disassembly Windows of Ozone only gives me DC32 32 bits hex value lines instead of basic disassembly.
Here "basic disassembly" is code disassembly without .elf file inserted labels, since Ozone doesn't support yet specifying at that entry a secondary .elf file, where to get the info.
So I would expect disassembly with hex values for address related references and dummy generic label generation for jump-to addresses.
Is there a way to get the disassembly window disassemble the information as code instead of only giving DC32 data disassembly lines?
Thanks,
RL
The context is ARM TMS570LC4357 MCU GNU cross-compiler on C, .elf file, 2 projects, second project is RAM loaded code
My ARM project code loads in RAM another ARM sub-project. The code is normally working but now I have a bug to locate and solve.
The problem: After loading the code in RAM, I call the RAM-based entry function of this code but the Disassembly Windows of Ozone only gives me DC32 32 bits hex value lines instead of basic disassembly.
Here "basic disassembly" is code disassembly without .elf file inserted labels, since Ozone doesn't support yet specifying at that entry a secondary .elf file, where to get the info.
So I would expect disassembly with hex values for address related references and dummy generic label generation for jump-to addresses.
Is there a way to get the disassembly window disassemble the information as code instead of only giving DC32 data disassembly lines?
Thanks,
RL
The post was edited 1 time, last by ReneLebel-BO: This specific problem as been partially solved by changing the linker file and tagging the region as 'x' executable. So now I have some level of disassembly. The main problems left are no support for breakpoint in the RAM code and no support of name mapping to alternate project. A proposal ticket as been written for this last issue, since simply adding secondary 'File.Open' lines for alternate .elf file could be supported because Ozone as access to all output sections of all projects and could senses context change and, in the case of RAM based code, could simply start using the secondary project context based on addresses used. ().