eZdsp '5535 - MicroSD Issue(s)

This should resolve your issue. The boot file name must be bootimg.bin. No #.

This is from Bootloader Apps Note.

http://www.ti.com/dsp/docs/litabsmultiplefilelist.tsp?sectionId=3&tabId=409&literatureNumber=sprabl7a&docCategoryId=1&familyId=325

• The boot image must be in the first partition with a filename of “bootimg.bin”.

Regards.

0312.test_boot.zip

Hello Steve,

Still having the problem for some reason - I have attached my .out file and .bin file - can you take a look at them and see if you can get your eZdsp5535 to run the files?

Thanks,
johnw 

To Those That May Know,

Is it valid to use 

-v5535 in the demo.cmd file - or not?

Thanks,
johnw 

If you are referring to hex55 command, then -v5535 is incorrect. It has to be -v5505 as stated in the Apps Note:

Use the following options on the hex conversion utility command line or command file:
hex55 -boot -v5505 -serial8 -b -o my_app.bin my-app.out
-boot: option to create a boot table
-v5505: use C55x boot table format for TMS320C5535/34/33/32
-serial8: boot mode is 8-bit standard serial boot
-b: desired output format is binary format
-o my_app.bin: specify the output filename
my_app.out: specify the input file

I have not had a chance to look into your tar file.

Regards.

Steve,

I wasn't sure - so thanks for clearing that up.

The zip file above was made with -v5505 so that you know.

Would be great if you could give it a try.  I cleared up any possible GEL file issues - removing all PLL inits, etc - the demo runs in the debugger ok but no joy when trying to run standalone.

Thanks,
john 

Hello All,

Hmmm, this question remains unanswered.

So, does the boot image have to be called bootimg.bin ?

And, can you run EZDSP5535_SPIFLASH_erase( 0, 7000000); for instance to make sure a bootable image isn't in the SPI FLASH?

And - for the '5535 this does not have to be encrypted, correct?

And - using something like Rufus is OK to make the SD Card with as a FAT32 formatted file: https://rufus.akeo.ie/ ?

Thanks,
John W.

I believe the image has the be called bootimg.bin.

The post-build command I use to make a file that works successfully is:

"${CG_TOOL_HEX}" -boot -v5505 -serial8 -b -o "bootimg.bin" "${BuildArtifactFileName}"

Hi John,

So, does the boot image have to be called bootimg.bin ?

Yes, bootimg.bin is correct for C5535. But I believe bootimg##.bin also works, where the priority is given to the lowest number.

And, can you run EZDSP5535_SPIFLASH_erase( 0, 7000000); for instance to make sure a bootable image isn't in the SPI FLASH?

We provide a programmer in the Chip support library. Also programmer_C5535_eZdsp.out on the Spectrum Digital Support page: http://support.spectrumdigital.com/boards/ezdsp5535/revc/

You can use a hex editor to clear the first two bytes of any bootimg.bin file to invalidate it - then program that invalid image into the SPI flash so that it never boots.

Or on the C5535 eZdsp, you can simply slide DIP switch pin 4 to the OFF position so that the SPI chip select never reaches the SPI Flash, and it can never boot.

And - for the '5535 this does not have to be encrypted, correct?

C5535 does not require encryption for SD card boot

And - using something like Rufus is OK to make the SD Card with as a FAT32 formatted file: https://rufus.akeo.ie/ ?

I have never used Rufus, but if it formats in FAT32, it should be fine. The bootimg.bin MUST reside in the top directory (it will not boot if it is inside any folder).

Refer to the bootloader appnote for more details.

Hope this helps,
Mark

bootimg1.zip

Mark,

Can you please try the attached on an eZDSP '5535?  I have been unable to get this to boot successfully from SPI FLASH or SD card.

Let me know if you get it to run - note this could end up being a double-post since the first time I tried to post this - I am not sure what happened.

The LEDs should cycle once SW1 and SW2 are pressed a couple of times.  Test Run->1 should display once the LEDs start to cycle.

Thanks In Advance,
John W.

Hi John,

It looks like the bootloader read the image from the SD card, but went off into the weeds. Program Counter = 0xD54575 after I powered the board with your bootimg in the SD card. I connected to the target without a GEL file and read the Core Registers: PC...

Whenever the bootloader is still running, the PC is somewhere in the ROM space (FE0000h – FFFFFFh) - probably executing the UART/USB boot portion of the bootloader.

Check the initialization of your program. Copy from some example that is known to work - like the Connected Audio Framework demo that comes with the C5535 eZdsp - 

                - http://www.ti.com/tool/c55x-audioframework

Hope this helps,
Mark

Hello Mark,

Thanks for doing this.

I had copied so to speak the demo that comes with the SPI FLASH code; since I have been trying both the SD Card and the SPI FLASH methods; and the demo that is included with the SPI FLASH seems to boot almost OK via the SD Card - the demo stops but not after it successfully runs the OLED display.

I will take a look at the Audio Framework demo.

Note I do call the "IDLE" instruction and all of that - I noticed that gave some people some grief getting the SD Card boot image working - in a lot of posts on this forum.

But I am calling SYS_ICR (I think that is correct as I don't have this project in front of me) - which is different than what is pointed out with the '5515. And, it doesn't seem to appear in any of the docs for the bootloader either.

Thanks,
John W.

Mark,

Can this be a problem when making a boot disk:

asm ( " bclr C54CM" );

// Change stack mode
if ( (DBIER0 & BIT2) == 0 )
{ // power-up case
DBIER0 |= BIT2; // indicator for next reset
asm(" reset"); // soft reset to change stack mode
}
else
{ // soft-reset case
DBIER0 &= ~BIT2; // put back to its reset state
}
asm ( " bclr C54CM" );

Thanks,
John W.

Hello Mark,

I got this to work - I made about the biggest mistake you can possibly make.

Both the SPI FLASH and SD Card are booting now.

Want to guess what it was?

Regards,
John W.

boots from SPI and From SD Card.zip

Hi John,

Congratulations on making it work.

Now I'm very curious what the biggest mistake you can possibly make is.

Was it a printf statement? Or maybe running code from SARAM31 that gets corrupted by the bootloader? Perhaps some assembly bug in the initialization or vectors.asm?

Regards,
Mark

Mark,

I had made a custom vectors.asm and in the linker control file it was putting the _Reset vector in the middle or so of SARAM31.
I had modified the gel file, but the project was finding another .ccxml file and was pulling in another .gel file of the same name when the debugger was invoked; making this a little harder to notice and a little less obvious to find. I must admit that is a 'feature' of CCS or eclipse I am not fond of. Nothing should be added to a code base that isn't explicitly understood as being part of a build or debug initialization.

But, it is working now and thanks for the replies from you and others that participated in this thread.

There is another curious issue I am seeing in the debugger; at certain places in the code; I think it is where context switching has taken place; the debugger will go into single step mode and halt saying it hit a hardware breakpoint; but I haven't set any hardware breakpoints.

Also, since changing the .gel file to a unique name plus the .ccxml file; I have to load symbols manually and I have noticed symbols from my assembly modules aren't loading now. Kind of curious as this was working albeit with the subsequent .ccxml and .gel files.

Thanks Again,
John W.

Mark/TI,

I started a couple of new threads on those issues mentioned in the previous post.

Mark - did you try loading the images? Just wondering.

And yes, at first I thought it was a printf - but I had made sure previously to make sure those were #ifdef-ed out. It's always easy to miss one.
That of course has bitten me before too; and I am sure others that are here.

Thanks and Have a Great Weekend,
John W.