Booting from NAND on a C6748 custom board

Hi Titus,

Thank you very much for your reply. I tried to do as you suggested but I am afraid it hasn’t been possible to run the StarterWare bootloader. To start with, my custom board has the BOOT pins configuration hardwired, it is not easy to change it to boot from UART. Secondly, since I have an LCDK board too, I tried to compile the bootloader with pre-processor definitions c6748 and NAND but got all sorts of errors. I had to comment out an #include “bl_am1808.h” in bl_config.h as I could not find it in my installation of StaterWare. Finally, it appears to have a conflict of constants and functions names. In bl_platform.c, it assigns constants to the NAND ECC info object:

   hNandEccInfo->ECCInit                   = EMIFANANDECCInit;

   hNandEccInfo->ECCEnable                 = EMIFANANDECCEnable;

   hNandEccInfo->ECCDisable               = EMIFANANDECCDisable;

   hNandEccInfo->ECCWriteSet               = EMIFANANDECCWriteSet;

   hNandEccInfo->ECCReadSet               = EMIFANANDECCReadSet;

   hNandEccInfo->ECCCalculate            = EMIFANANDECCCalculate;

   hNandEccInfo->ECCCheckAndCorrect       = EMIFANANDECCCheckAndCorrect;

But these constants are not defined anywhere. Instead, nand_emifa2.h declares them as functions:

extern NandStatus_t     EMIFANANDECCInit(NandInfo_t *nandInfo);

extern void             EMIFANANDECCEnable(NandInfo_t *nandInfo);

extern void             EMIFANANDECCDisable(NandInfo_t *nandInfo);

extern void             EMIFANANDECCReadSet(NandInfo_t *nandInfo);

extern void             EMIFANANDECCWriteSet(NandInfo_t *nandInfo);

extern void             EMIFANANDECCCalculate(NandInfo_t *nandInfo, unsigned char *ptrEccData);

extern NandStatus_t     EMIFANANDECCCheckAndCorrect(NandInfo_t *nandInfo,

                                               unsigned char *eccRead,

                                               unsigned char *data);

I have StarterWare version 1.20.03.03.

Mayela

Hi Titus,

Thanks once more for your reply.

I am testing your suggestion on the LCDK board before I move to the custom board. The LCDK have configurable BOOT pins, so I tried first using the serial utility sfh_OMAP-L138.exe. Using the SFH utility with the StarterWare bootloader and the application’s binary file generated with out2rprc.exe works well. It boots from flash after changing the BOOT pins to NAND and executes the application code as expected.

However, in order to use the StarterWare bootloader with the CCS flash utility NANDWriter_DSP, I need to generate a single AIS file containing the bootloader and the application’s binary file. For the later, I need to provide an address where this binary file will be located. I tried the default address @0x80000000. AISGen automatically adds this address when adding a binary file to the “DSP application file” input field. Also, I tried with the entry point address, or _c_int00 for my application, but none of them worked.

Could you please try to replicate my situation using the LCDK board? I am attaching the application .out file. It should just toggle two LEDs.

Regards,

MayelagpioSample.zip

However, in order to use the StarterWare bootloader with the CCS flash utility NANDWriter_DSP, I need to generate a single AIS file containing the bootloader and the application’s binary file. For the later, I need to provide an address where this binary file will be located. I tried the default address @0x80000000. AISGen automatically adds this address when adding a binary file to the “DSP application file” input field. Also, I tried with the entry point address, or _c_int00 for my application, but none of them worked.

Hi Titus,

Sorry, I wasn't aware that the bootloader sends messages to the UART port. I have just connected the USB-UART port to the PC and I get this on the serial terminal:

StarterWare C6748 Boot Loader

 Reading Image From NAND ...NAND Read Failed.

Regards,

Mayela

Hi Titus,

Thanks for your help. It was a bit complicated to add a custom linker command file without getting linking errors, so I initialised the section map in the .cfg file.

Program.sectMap[".cinit"] = "IRAM";
Program.sectMap[".pinit"] = "IRAM";
Program.sectMap[".init_array"] = "IRAM";
Program.sectMap[".binit"] = "IRAM";
Program.sectMap[".const"] = "IRAM";
Program.sectMap[".switch"] = "IRAM";
Program.sectMap[".text"] = "IRAM";
Program.sectMap[".text:_c_int00"] = { loadSegment: "IRAM", loadAlign: 0x400 };
Program.sectMap[".neardata"] = "IRAM";
Program.sectMap[".rodata"] = "IRAM";
Program.sectMap[".bss"] = "IRAM";
Program.sectMap[".far"] = "IRAM";
Program.sectMap[".fardata"] = { loadSegment: "IRAM", fill: 0x0 };
Program.sectMap[".stack"] = "IRAM";
Program.sectMap[".sysmem"] = "IRAM";
Program.sectMap[".cio"] = "IRAM";
Program.sectMap[".vecs"] = "IRAM";

I found other sections in the automatically generated linker.cmd file, so I am also loading them on IRAM.

Program.sectMap[".ti.decompress"] = "IRAM";
Program.sectMap[".ti.handler_table"] = "IRAM";
Program.sectMap[".c6xabi.exidx"] = "IRAM";
Program.sectMap[".c6xabi.extab"] = "IRAM";
Program.sectMap[".data"] = "IRAM";
Program.sectMap[".args"] = { loadSegment: "IRAM", loadAlign: 0x4}

I converted the .out file to .ais using the LCDK AISGen configuration, flashed it to the custom board and it works! It boots from NAND Flash.

So, my guess is that there is something wrong in the settings of the DDR in the custom AISGen configuration file. I would be surprised if this is the case, because I derived the values of the registers in the PLL0, PLL1 and DDR tabs from the custom GEL file. What else could I be doing wrong? Do I need to specify an entry point for the DDR-based application?

Best wishes,

Mayela

Hi Titus,

I'm working with Mayela on this problem, and it occurs to me what I need to do next is get the debugger connected to the bootloader.

I would like to trace the progress of the AIS being read from the flash and the setup of the various registers to see at what point things differ from the working system on the LCDK board.

Is this possible?  Is there an appnote or similar you could point to?  What I am envisaging is being able to connect the debugger and then perform a reset on the DSP, and then single-step it from there.

Any guidance you could offer will be greatly appreciated!

Thanks,
Martin

I converted the .out file to .ais using the LCDK AISGen configuration, flashed it to the custom board and it works! It boots from NAND Flash.

So, my guess is that there is something wrong in the settings of the DDR in the custom AISGen configuration file. I would be surprised if this is the case, because I derived the values of the registers in the PLL0, PLL1 and DDR tabs from the custom GEL file. What else could I be doing wrong? Do I need to specify an entry point for the DDR-based application?

Thanks Titus - yes I understand that, but given we have

* a working app (as proven on the LCDK, and via the debugger on our custom board)

* what we think are all the right settings for the AIS config - as they work in the GEL file we use with the debugger.

I am assuming something is going wrong in the process of the AIS being read from flash (or I guess in the process of writing it to the flash - does the flashwriter do some kind of checksum after programming?)

Can you advise what would be the recommended approach to debugging at this stage?

Thanks,

Martin

Hi Titus,

Thank you very much for your message. Your AIS configuration file indeed works well for the LCDK, however it doesn’t work for the custom board.

This has been always the case. The LCDK successfully boots from NAND when the application AIS file is flashed to the board using either the SFH serial flasher or the NANDWriter from CCS.

The problem is the custom board. Its boot pins are hardwired to boot from 16-bit NAND, block 1. Therefore, I cannot use the SFH serial flasher. Initially, when I started this thread, I thought that the problem was the NAND memory.

Your first suggestion, to use the StarterWare bootloader, neither works on the custom board nor on the LCDK board, when using the NANDWriter from CCS to flash to the board. This could be because neither of us knows which address to provide as an entry point for the application’s RPRC binary file when converting the bootloader .out file and the application’s RPRC file to AIS with AISGen utility.

Your next recommendation was to configure the application to run from internal RAM and flash it to the board using NANDWriter. This worked well for both, the LCDK and the custom boards, singling out the DDR settings for the custom board in the AISGen configuration as the most likely cause of the problem.

Having proved that the code can be flashed to the custom board with NANDWriter and that the custom board can boot from NAND when running the application from internal RAM, we directed our attention on the AIS settings for DDR.

The custom board mDDR is an IS43/46LR16800F with 128Mb organised as 2M x 16bits x 4 banks. Its timing parameters are different to those of the DDR on the LCDK board.

The mDDR settings in the custom GEL file work well for the custom board when running the code in emulator mode, but the same settings in the AISGen file fail to correctly configure the external memory when booting from NAND.

So, my next question is why the same DDR settings work well when running the code in emulator mode but not when booting from NAND?

Best wishes,

Mayela

Actually, scratch my queries about the PLL1 config - Mayela pointed out to me that the PLL1 config can also be done in the DDR setup command!  

So, the problem remains (as Mayela's most recent message also said), "why do the settings that work when configured via GEL not work when configured via AIS?"

I have done some more digging - looking at the AIS file hex, it appears that the PLL1 is not being configured... I assume that might cause some problems with the DDR boot?

So, the problem remains (as Mayela's most recent message also said), "why do the settings that work when configured via GEL not work when configured via AIS?"

Hi Titus,

The custom board has a completely different DDR part - it is mDDR and we have a custom GEL file.  I have used CCS to load the application code, and the GEL file.  The application runs fine.  I have extracted the PLL and DDR config registers from the DSP and put them into the appropriate places in the AIS file, and they appear to be correctly set in the AIS output file which is then burned into the flash.

I have verified that the PLL registers are correctly configured by the bootloader (by connecting the debugger without a GEL file) - I have changed one of the values slightly to verify that I am not inadvertently rewriting the setup with a GEL file, and they are being configured correctly.

So I'm afraid the question still remains:

Why are the register values which work when programmed via a GEL file not allowing the DSP to boot when the same values are used in the AIS config?

What else can we try?  What else can go wrong? Are we the first to have trouble of this sort?

Thanks,

Martin

Hi Titus,

Thanks again for your answer. Martin has already clarified the issue about the memory part. Are you suggesting that if the DDR settings are borderline they might work in emulator mode but not standalone? Is there a reason for this?

I found a similar post which might be worth exploring: http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/119596/431543

Best wishes,

Mayela

Thanks again for your answer. Martin has already clarified the issue about the memory part. Are you suggesting that if the DDR settings are borderline they might work in emulator mode but not standalone? Is there a reason for this?

The custom board has a completely different DDR part - it is mDDR and we have a custom GEL file.

Hi Titus,

The engineer who designed the board derived the DDR parameters for the mDDR part in the custom board. He left the company a few months ago and we have lost contact with him.

The custom board GEL file has these DDR parameters. They are different to the LCDK parameters. This GEL file seems to be doing the DDR configuration correctly because the code runs from DDR in emulator mode. The same parameters do not work in the AIS file.

Best wishes,

Mayela

Sure, these are the two files requested.

Cheers,

Mayela

C6748_MZ.gel

myAisGenConfig.cfg

Forgot to add this: the mDDR part number is IS43LR16800F-6BLI.

Mayela

IS43LR16800F-6BLI DRAM 128M (8Mx16) 166MHz Mobile DDR 1.8v.pdf

Hi Titus,
I am reading the document SPRUGJ4B DDR2/mDDR Memory Controller and I getting a bit confused. Does BOOTUNLOCK need to be set to 1 to be able to change the settings from DDR2 to mDDR?
Do you have a typical GEL file or AIS config for mDDR?
Best wishes,
Mayela

Latest update. Connecting to the target using the emulator, I can see the value of 0xA55AA55A at location 0xC0000000. My guess is that this value is written by the ROM's bootloader code as part of the DDR's initialisation. It seems to be able to access the DDR, to write on it, but it doesn't load the application's code on it.

Mayela