Codestart or C2800.init.Boot?

Justin,

Which device are you using?  I expected a begin address of something like 0x3F7FFE or 0x3F7FF6.

Also, which RTSC platform are you using?  Is it “ti.platforms.tms320x28”, or something else?

Thanks,
Scott

I am using an F28335. I built a custom platform based off the EZDSP28335 and have added a few custom memory sections in the map. Here is the TCF file I used to convert it, and the Platform.xdc that was created from the conversion.

2438.Platform.txt8623.Semikron_DCDC_v05.tcf.txt

Justin,

OK, thanks for the additional info.

When you enable the boot-to-flash option with the Boot module it will emit a long branch to the program entry point, into a memory region named “BEGIN”.  The location of BEGIN is defined as the boot-to-flash entry point in the device datasheet. 

In the newer “generic” platform (named “ti.platforms.tms320x28”) we provide linker command files for the different supported devices, in that platform’s include subdirectory.  For example, the file ti/platforms/tms320x28/include/TMS320F28335.cmd is a starter linker command file, with this:

    BEGIN       : origin = 0x33FFF6, length = 0x000002     /* Used for "boot toFlash" bootloader mode. */

For the older ti.platforms.ezdsp28335, the platform doesn’t provide a starter linker command file.  In the linker command file you are using, BEGIN_FLASH is at the same location, and will cause a jump to some other location.  I don’t know where that is, but it may be that it is pointing off into the weeds, causing a crash, and causing ROV to display corrupted values.   

Can you determine what component is placing something at  BEGIN_FLASH?  (The map file shows the locations as used.)  And stop that, and then modify your linker command file to change the name to “BEGIN” instead of “BEGIN_FLASH”?  Then, hopefully the program will boot…

Another option would be for you to switch to use the new ti.platforms.tms320x28.  I don’t know if that is an option for you, but it is the preferred platform we’ve been pointing people to.

Hope this helps.

Scott

I renamed "BEGIN_FLASH" to "BEGIN", and changed a few things, but I'm still left with the same result.

After renaming and rebuilding, the use of :

var Boot = xdc.useModule('ti.catalog.c2800.init.Boot');

Boot.bootfromFlash = true;

causes it to be place in BEGIN automatically.  This then causes a 1099-D error when the linker tries to put codestart in there. If I exlude the codestart.asm and the section declaration, the program will build, and BEGIN will have the ti.catalog.c2800.init.Boot in the BEGIN section.  This causes the ROV to still give the error that it is off in the weeds.

If I comment out the ti.catalog.c2800.init.Boot in the cfg file, and include codestart.asm and allocate codestart to BEGIN, the program builds and the ROV gives the same exact error, pointed to the same non-existant memory location.

If the "Boot from flash" checkbox is checked, does one normally have to comment out the allocation for codestart?

Justin,

I don’t know where that codestart code is coming from.  Can you post the contents of that .asm file?

Also, can you describe how you are booting and debugging the device?  Are you letting it boot from flash, and *then* connecting with CCS?  When CCS connects, is it possible CCS is reseting the device?

Also, when looking at ROV, has the program at least run to main()?  ROV will look at data structures that need initialization, and can report errors if those structures have not been initialized yet.

Also, besides what ROV indicates, is the program otherwise running?  Or is the CPU really off in the weeds?

Thanks,
Scott

8105.CodeStartBranch.txt

here is the CodeStart.asm file.  This was in my project from before when it was a DSP/BIOS 5 program.

I am unsure of what different ways there are to boot and debug this device; I've always done it the same way:

power the "ELX" pin with 35 V, 10 mS before I apply 24 V power. then just select debug in CCS. That prompts an erase and reprogram of the flash sectors and it used to always run to main() and halt.  It no longer runs to main. The debugger shows it is running, and if I halt it in the right spot (by repeatedly starting and halting it) I can stop it when it is is debuggable code, usually a SWI. If it doesn't go into debuggable code when I halt it, a mostly blank tab pops up titled "0x33ff9ce" and on the page, "no source available for '0x3ff9ce'"

Also, looking at the disassembly, there are a lot of zeros and "ITRAP0" where BEGIN and PASSWORDS are, as shown.  I've only been able to find that this means the device is locked; is that what this symptom is?

Actually, I just programmed the device with the original DSP/BIOS program and it acted normally.  It ran to main() and the disassembly looks normal (I think), so maybe that's not what that meant before.

Justin,

Sorry for the slow reply, I missed your response somehow.

Thanks for the asm file.  Is the “wd_disable” in your new application, and being called somehow?  I’d guess that it is, but maybe the watchdog is going off?

From what you describe, if CCS is loading flash as it starts up then you are really not in the flash boot mode.  Unless there is something really special happening in a GEL file that maybe resets the device after loading the flash.

The address of 0x3FF9CE is in the boot ROM, not in the writable FLASH region.  It seems after CCS starts that it runs the CPU, something bad happens, the device gets reset, and ends up back in its bootloader.

In CCS can you disable the automatic go to main() [right click on the project, select Properties, then Debug, then “Auto Run and Launch Options”, and uncheck the two boxes under “Auto Run Options”, then Apply, and OK], and then start the same way, and after CCS loads the program the PC should be sitting at the program entry point.  Is this address what you would expect?  Can you step the program in the debugger to see what happens from that point?

Scott

After disabling the automatic run to main, the first thing that happens in the debugger is this error page:

and the pointer is sitting at 0x305452, where c_int00 is.

After the first step, it jumps to 0x3ff934 and allows me to step a few more times until it gets to 0x3ff9fa and stops and will not step any more.

OK, thanks.  So it looks like the c_int00 program entry point has nothing written by the loader.  And when you step the CPU it immediately gets vectored back into the device boot ROM.

In your map file do you show anything being placed at 305452?

Also, can you post a screen shot of the project’s RTSC properties page?  Right click on the project, select Properties, click General, and then the RTSC tab.

Thanks,
Scott

According to the Global Symbols list, _c_int00 is at 305452.

Here is the RTSC properties page.

Hi Justin,

So it would appear that for some reason part of the boot code isn't being programmed into flash.  Could you attach a full copy of your map file for me to look over?  We need to understand exactly why this is happening.  It could be that the linker is not linking it into the final output OR there could be a bug with flash programming.  Would you also mind looking around at the flash memory after it has been programmed to see if more of your sections are missing?

Regards,

Look like your post got messed up

• 7128.Map.txt

Here is my map file.  I am unsure how to look through the flash after it has been programmed>. Do you mean via the disassembly in the debug view?

Ah, that does make sense.  I'm not sure why that is the case though.  in my cfg file, i have:

//Program.sectMap[".text"] = new Program.SectionSpec()
Program.sectMap[".text"] = new Program.SectionSpec();
Program.sectMap[".text"].runSegment = "FLASH";
Program.sectMap[".text"].loadSegment = "FLASH";

and in the generated linker.cmd there is:

SECTIONS
{
    .text: load >> FLASH PAGE 0, run >> FLASH PAGE 0
    .switch: load >> FLASH PAGE 0, run >> FLASH PAGE 0
    .data: load >> FLASH PAGE 0
    .cinit: load > FLASH PAGE 0, run > FLASH PAGE 0
    .bss: load > L27SARAM PAGE 1
    .ebss: load >> L27SARAM PAGE 1
    .econst: load >> FLASH PAGE 0
    .const: load >> FLASH PAGE 0, run >> SRAM PAGE 1
    .stack: load > MSARAM PAGE 1
    .sysmem: load > L27SARAM PAGE 1
    .esysmem: load > L27SARAM PAGE 1
    .pinit: load > FLASH PAGE 0, run > FLASH PAGE 0
    .args: load > L27SARAM PAGE 1 align = 0x4, fill = 0 {_argsize = 0x0; }
    .cio: load >> MSARAM PAGE 1
    .ebss:taskStackSection: load > SRAM PAGE 1
    .reset: load > MSARAM PAGE 1
    .ti_catalog_c2800_init_begin: load > BEGIN PAGE 0
    xdc.meta: load > FLASH PAGE 0, run > SRAM PAGE 1, type = COPY

}

and in my linker.cmd file, I added

.text     : > FLASH, PAGE=0

and it is still identical to before.  Is there something else that needs to be changed?

Nevermind, I removed the runSegment line in the cfg file and it removed the designation from the map.