Problem with Booting from Flash on DM648

The NOR boot mode should be usable with your clock, it will just mean that some of the timings will be faster, this really is only a major limitation to the UART boot mode which would not sync properly with a offset clock frequency

As to the actual problem at hand, when you go to debug the boot process are you getting any ERR value in the BOOTCMPLT register? If so than that may help point us in the right direction to fix this issue. 

BOOTCMLPT is mentioned in section 3.2.3 of the DM648 datasheet.

Thanks for your response. BOOTCMPLT does show a value of 0!!

Regards

Suba

When Fastboot=0, is the NOR boot method just like the EMIF bootmode in DM642?

Will the processor copy the first 0x400 bytes from flash to IRAM?

Or does it just jump to the NOR base address 0xA0000000 and we need to write a bootcode there to copy our UBL and our application from flash?

Is the hex6x conversion used for DM642 still valid?

Subashini said:

When Fastboot=0, is the NOR boot method just like the EMIF bootmode in DM642?

Will the processor copy the first 0x400 bytes from flash to IRAM?

Or does it just jump to the NOR base address 0xA0000000 and we need to write a bootcode there to copy our UBL and our application from flash?

Assuming you mean BOOTMODE[3:0]=0100b with FASTBOOT = 1 than no, this uses an Application Image Script format described in SPRAAJ1, whereas the DM642 would just do a 1k copy from the beginning of flash to internal RAM (which would typically be your secondary boot loader) and run it. The AIS script means you no longer need to have your own 1k boot loader, and makes initializing the device easier.

With FASTBOOT = 0 it is more similar to DM642, however it does not do the 1k copy, it just branches to the beginning of flash memory (0xA0000000).

Subashini said:

Is the hex6x conversion used for DM642 still valid?

This depends, the hex6x utility was for turning a .out file into a .hex file, i.e. from a binary image to a ascii image, for the purposes of being compatible with flash burning utilities. At least with the DM648EVM DVSDK software it does not seem to use hex6x, as the flash burning utility that comes with the package uses a binary when burning the flash, you can find more details on the project conversion and burning process within the FlashUtil folder of your DVSDK install, i.e. C:\dvsdk_x_xx_xx_xx\FlashUtil.

Hi,

We have been following the FlashUtil in the dvsdk and the spraaj doc.

We still have the same problem: when trying to boot from NOR flash (FastBoot=1, bootmode[3:0]=0100), like before the still just jumps to the application start address, but the application code does not run.

But found something strange: Keep the emulator connected, power-cycle the board to boot from flash, then open CCS and again close CCS. Then the application in flash runs correctly.

In CCS we do not give any gel file or run any code. Just open and close CCS helps to run the flashed application.  Any ideas why would that be.

Thanks a lot.

That sounds like something in a GEL file would be fixing it, are you sure you do not have a GEL file in your CCS setup? Note that a GEL file in the CCS setup will run on its own upon connecting to the target.

We do Not add a GEL file in the CCS3.3 SetUp.

If we keep the emulator powered-up, then on power-on, the UBL does Not come up, then on CCS open and close, the UBL runs and the application also runs.

If we do not have the JTAG connected to the board, on power-up, the UBL runs, loads the application, finds the correct jump address, but does not jump to the application.

The power sequencing and the resets seem to be withing the prescribed limits. Any ideas why this might be happening? Thanks a lot for your time and effort.

This is a tough one, the main thing that CCS could do to change the state of the system would be to run the GEL file, so if there is no GEL file it could be that somehow the act of stopping and starting the CPU is allowing it to go but I am not sure how. Since BOOTCMPLT is 0 that indicates that at least the ROM boot loader thinks that the boot was successfull. To debug further my next thought would be to see where the program counter is when you connect to try to see where it is going wrong.

The UBL included in the DVSDK is very tailored to the Lyrtech EVM, and was not intended to be used with a custome platform without modification.  That being said, one way to approach this problem is to make the UBL as simple as possible (a while(1) loop for example) and then progressively add back in functionality before the UBL enters this while loop.  Keep doing this until things break.  Once you have a UBL that can do everything you need it to do correctly, then remove the while loop and let it try to enter into the actual application that you are trying to boot.

Regards,

Daniel

Thanks a lot for pointing in the right direction.

Apparently, the DDR used on the board was changed from the original schematic to MT47H64M16HR -3 IT:E. The main difference from the DDR part on the EVM is in the CL=5 and in REFRESH time. Could that be the cause?

I am able to boot a small LED blinking application from DDR. But still have trouble when using a .tcf file. The tcf file is used only for memory allocations for all the sections to DDR. Have not initialized any Tasks or other objects. Any ideas.

If the DDR timings are marginal on the new part that could explain instability in anything that you try to place into the DDR, but I would expect even a simple LED blinking application to be unstable if the DDR is not stable. Using BIOS with a TCF file may change where things are allocated and can make the project a bit larger but should not directly relate to the DDR. One thought to test this further would be to put a simple read write memory test into the blinking LED program you have running now, that way you can more solidly verify the stability of the DDR which would narrow the issue down to something unique to the project with a TCF file.

I am able to run the DDR test code from IRAM and this tests all the DDR memory. This passes fine.

No interrupts or tasks are enabled in the tcf file. Still if I run the UBL from CCS, the application runs correctly.

The Interrupt EVTFlags are a little different when booting from flash:

EVTFLag[0]= 0xE

EVTFlag[1]=0x8

EVTFlag[2]=0x10

EVTFlag[3]=0x1000000

When will there be an IDMA Bus error?

Thanks.

I am not sure why you ask about an IDMA Bus error as I don't see one in the EVTFlag[3] register contents; however, I would imagine that an invalid configuration such as the source/destination address set to external memory would cause a bus error.

Are there any other significant differences between the DM648 EVM and your custom hardware aside from the DDR2? Are you working with different a different CPU frequency (PLL configuration) or anything like that?

Occasionally I see a 0x90000000 or  0x80000000 or  0x10000000 in the EVTFLAG[3]. The DM648 datasheet talks abt IDM bus error or a CPU memory protection fault. Was wondering if these have any bearing to the current problem or some measurement glitches when CCS is trying to access some reg value for its real-time update.

The DM648 input clock was initially at 33 MHz, 891MHz DSP; The PLL multiplier reg value is 26.

Now the input clock is at 27MHz, the PLL multiplier is at 32 (864MHz DSP, the PLL multiplier register value is 31).

I spent a bit of time working on the DM648 Bootloader this afternoon and managed to successfully get a DSP/BIOS-based project to bootload from Flash. Here are a couple key notes I took from this:

- I rebuilt the UBL project (found in \flashutil\DM647_8\CCS\UBL) using my current CodeGen Tools (6.1.5). This is what I used to build my LED project. Note that I built this with the Debug configuration instead of DDR_512MB.

- Ensured that *everything* was loaded into DDR2 and that nothing was loaded into internal memory. If anything is located in internal memory there’s a chance it will overwrite the UBL code at run-time.

- Verified that the flash burned correctly.

- Verified that the key DSP registers (PLL, DDR2, etc.) in the UBL matched the register values in the GEL. Note that in the case of custom hardware that the UBL peripheral configuration values must be modified to match the hardware on the custom board (edit the device.c file).

- Copied updated UBL.out and my led.out file into the \flashutil directory.

- Ran create_ais.bat file.

- Loaded NORWriter.out and burned UBL.out + led.out.

- Ensured the DM648 was in the proper boot mode.

And that’s about it. Because I am working on the DM648 EVM and not custom hardware I believe that the portion highlighted in red above will be the most likely culprit for issues on custom hardware with the current UBL-based approach.

I was able to run a LED blink routine from the the DSP/BIOS init function, but it did not go to my main() in the application.
 
The Program Counter was looping endlessly at HWI1 (NMI). Once I put an empty callback function for the NMI, everything started working fine.

Thanks for all your support, time and your valuable inputs. Looks like there is an external pull-up to the NMI pin causing the problem.

Suba, Tim,

Thanks for driving this to closure and identifying the underlying cause.

Regards, Daniel

Hi Subashini,

Hi this is geetha working in Japan. I am struck with the same issue as you mentioned in your mail...

The above lines of yours ..is exactly..I am facing

i.e

"We are using Fast Boot option and trying to boot the DM648 from a NOR flash. We use the instructions in the flashutil to write the ais image of the UBL code and the application code to the flash.

On flash booting, the ais image is parsed successfully by the UBL. It also finds the correct application jump address in DDR. But the application does not run.

On debugging we found that the DDR and PLL settings are set correctly by the UBL and the application code has also been copied to the DDR correctly.

When we run the same UBL with the emulator, that also correctly copies the application code to the DDR and runs it correctly."

"Why would the application image be copied correctly, but the UBL does not seem to jump to that image even after finding the correct app entry point and after the calls:

            bootFunction = entryPoint;
            (*bootFunction)();"

Even I checked your other post where u said you could fix it by putting some callback function at HWI/NMI  settings.I did not know how to do it.

and Even our application also uses dsp/bios settings.So I would like to try with the same thing as you did.

But I am  working on the target board that uses TIDM648 and the flash model is LH28F160BJE-TTL90(Client specification) and product 16M (x8/x16) Flash Memory.

Code generation tool is 6.1.5 version.

NOTE:The same strange thing I could see that "

But found something strange: Keep the emulator connected, power-cycle the board to boot from flash, then open CCS and again close CCS. Then the application in flash runs correctly.

In CCS we do not give any gel file or run any code. Just open and close CCS helps to run the flashed application"

please suggest me for the same.