Can't Flash C6748 image that runs under emulation

Hello,

The board is custom.

I don't think it is boot mode. But I wasn't clear on your suggestion of how to use emulation mode or UART boot mode, to check. When reloading the application code, after the flash run fail, I see that the code is running, just that the LEDs are not blinking. It is possible that when I am running the same code out of flash, stand-alone, it too is also running, but the LEDs are not blinking.

I have added LED blink code in my actual code. And it runs if a) the simple flash LED program is resident in flash on power-up, and 2) I am running my application code using the emulator.

I have double checked that the PSC is enabled for the peripherals, but I will check again.

I am not using a gel file when running in emulation. All initialization is done in the startup/initialization portion of my application code. I assume this would have to be the case anyhow, since there is no GEL initialization when running out of flash. All must be done by the code.

But I agree it may be that I am missing some initialization. And that when the simple LED program is in flash, it does that initialization on board power-up, so then when I run my application code under emulation, things are ok. But when I put my application code in flash, the missing initialization is not done at power-up, so when I try to run the application code under emulation, the lacking initialization results in the LEDs not working.

That is a theory, anyhow, at this point.

Any other suggestions or pointers on how to debug this are appreciated.

Thanks,
Robert

This morning, I put all the "simple led" initialization and led run in my application code. At startup, all it does is the exact same initialization and led sequencing as the simple led program that runs successfully out of flash. I then flashed it in, and the led sequencing was not working. So it doesn't appear to be just initialization, that the simple led program does and my application code doesn't. Unfortunately, that makes the problem even harder to figure out. So again, any assist appreciated.

Robert

The PLL and DDR initialization is NOT something we expect you to do in your application code. In a CCS environment, this would be done inside the gel file. When you migrate to a stand-alone application, that setup should be handled as part of the AIS headers (i.e. by the ROM code). Structuring your code in this way allows you to link/load code and data directly into DDR. Otherwise, you end up with sections like .cinit which get used only one time ever (i.e. before main) taking up precious internal RAM.

Code Composer will use a GEL script from it's own install directory. The GEL script prints out to the debugger console while loading up your image. Something like:
Target Connected
DDR initialization is in progress....
PLL0 Init done for Core
PLL1 Init done for DDR
Other evidence of the GEL script being used is the extra menu items on CCS like Clean Memory Map, Setup Memory Map, etc.

I have never used HEXAIS. I suspect it does not add any extra init commands to it's output. I would suggest using AISGEN and experiment with the peripheral init settings. In particular, whatever peripheral your app is using but the LED example is not.

Norman Wong said:

I have never used HEXAIS. I suspect it does not add any extra init commands to it's output.

There's an ini file that the user fills out to specify clocks, DDR parameters, PSC, etc.  Personally I find hexais much better than AISgen as you have much more control over the resulting output.

On a related note, let's stick with the LED example for now...  If we can't get that working, we have little chance of getting the full application working properly!

Out of bit desperation (deadline), I took a different tact: moved all the application code into the simple led project. And yep, I hosed it up :) I can build the simple led project, but it no longer runs out of flash (I can flash it in, but like app code used to be, it doesn't flash the leds). I didn't really change the led program at all. And I've since tried to back out all the app stuff, but still no luck.

I'm back to a working, flash-able simple led program, after taking out all additions from the app code (blinks leds stand-alone). I'll try and add in one by one, the app code things, to see if I can find the break point. A big difference between the simple led program, and my app code, is the use of a .tcf file in the app code. I think that pulls in a lot of stuff, that may be a factor.

Can you please try to use debug gel file after your application code hangs ?
processors.wiki.ti.com/.../OMAP-L1x_Debug_Gel_Files
It would give you the PC and you can findout where the code is getting stuck.

Robert56682 said:

I'm back to a working, flash-able simple led program, after taking out all additions from the app code (blinks leds stand-alone).

Can you confirm:

1. The PLL+DDR configuration is done by the boot ROM, based on AIS commands stored in the flashed image.
2. Your application (or the LED application) never ever again touches the PLLs or DDR, i.e. you should NOT reconfigure them.

Robert56682 said:

I'll try and add in one by one, the app code things, to see if I can find the break point.

Related to my items above, if you're reconfiguring the DDR and there is code/data residing in DDR, then you might be inadvertently trashing that memory.

To be honest, I don't think it's hanging. Leading suspicion is that it is running, but something is not initialized right so the leds don't flash. But I did flash in the app code, confirmed no leds, and then ran the debug gel. Output is below. Please review and see if there is any clues.




C674X_0: GEL Output:
---------------------------------------------
C674X_0: GEL Output: | Device Information |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: DEV_INFO_00 = 0x1B7D102F
C674X_0: GEL Output: DEV_INFO_01 = 0x00000000
C674X_0: GEL Output: DEV_INFO_02 = 0x0000000C
C674X_0: GEL Output: DEV_INFO_03 = 0x00000002
C674X_0: GEL Output: DEV_INFO_04 = 0x00000000
C674X_0: GEL Output: DEV_INFO_05 = 0x000003E0
C674X_0: GEL Output: DEV_INFO_06 = 0x00000200
C674X_0: GEL Output: DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 0-0-5635612-6-35-29
C674X_0: GEL Output: DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 2,0,0,5019
C674X_0: GEL Output: -----
C674X_0: GEL Output: DEV_INFO_17 = 0x00030003
C674X_0: GEL Output: DEV_INFO_18 = 0x00000000
C674X_0: GEL Output: DEV_INFO_19 =C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output:
C674X_0: GEL Output: -----
C674X_0: GEL Output: DEV_INFO_20 = 0x30303864
C674X_0: GEL Output: DEV_INFO_21 = 0x3630306B
C674X_0: GEL Output: DEV_INFO_22 = 0x00000000
C674X_0: GEL Output: DEV_INFO_23 = 0x00000000
C674X_0: GEL Output: -----
C674X_0: GEL Output: DEV_INFO_24 = 0x0601D023
C674X_0: GEL Output: DEV_INFO_25 = 0x0055FE1C
C674X_0: GEL Output: DEV_INFO_06 = 0x00000200
C674X_0: GEL Output: DEV_INFO_26 = 0x27360002
C674X_0: GEL Output:

C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: | BOOTROM Info |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: ROM ID: d800k006
C674X_0: GEL Output: Silicon Revision 2.0
C674X_0: GEL Output: Boot pins: 12
C674X_0: GEL Output: Boot Mode: SPI1 Flash
C674X_0: GEL Output:
ROM Status Code: 0x00000000
Description:C674X_0: GEL Output: No error
C674X_0: GEL Output:
Program Counter (PC) = 0x11822ECC
C674X_0: GEL Output:
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: | Clock Information |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output:
C674X_0: GEL Output: PLLs configured to utilize crystal.
C674X_0: GEL Output: ASYNC3 = PLL0_SYSCLK2
C674X_0: GEL Output:
C674X_0: GEL Output: NOTE: All clock frequencies in following PLL sections are based
C674X_0: GEL Output: off OSCIN = 24 MHz. If that value does not match your hardware
C674X_0: GEL Output: you should change the #define in the top of the gel file, save it,
C674X_0: GEL Output: and then reload.
C674X_0: GEL Output:
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: | PLL0 Information |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output:
C674X_0: GEL Output: PLL0_SYSCLK1 = 300 MHz
C674X_0: GEL Output: PLL0_SYSCLK2 = 150 MHz
C674X_0: GEL Output: PLL0_SYSCLK3 = 25 MHz
C674X_0: GEL Output: PLL0_SYSCLK4 = 75 MHz
C674X_0: GEL Output: PLL0_SYSCLK5 = 100 MHz
C674X_0: GEL Output: PLL0_SYSCLK6 = 300 MHz
C674X_0: GEL Output: PLL0_SYSCLK7 = 50 MHz
C674X_0: GEL Output:
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: | PLL1 Information |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output:
C674X_0: GEL Output: PLL1_SYSCLK1 = 300 MHz
C674X_0: GEL Output: PLL1_SYSCLK2 = 150 MHz
C674X_0: GEL Output: PLL1_SYSCLK3 = 100 MHz
C674X_0: GEL Output:
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: | PSC0 Information |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output:
C674X_0: GEL Output: State Decoder:
C674X_0: GEL Output: 0 = SwRstDisable (reset asserted, clock off)
C674X_0: GEL Output: 1 = SyncReset (reset assered, clock on)
C674X_0: GEL Output: 2 = Disable (reset de-asserted, clock off)
C674X_0: GEL Output: 3 = Enable (reset de-asserted, clock on)
C674X_0: GEL Output: >3 = Transition in progress
C674X_0: GEL Output:
C674X_0: GEL Output: Module 0: EDMA3CC (0) STATE = 0
C674X_0: GEL Output: Module 1: EDMA3 TC0 STATE = 0
C674X_0: GEL Output: Module 2: EDMA3 TC1 STATE = 0
C674X_0: GEL Output: Module 3: EMIFA (BR7) STATE = 0
C674X_0: GEL Output: Module 4: SPI 0 STATE = 0
C674X_0: GEL Output: Module 5: MMC/SD 0 STATE = 0
C674X_0: GEL Output: Module 6: AINTC STATE = 3
C674X_0: GEL Output: Module 7: ARM RAM/ROM STATE = 3
C674X_0: GEL Output: Module 9: UART 0 STATE = 0
C674X_0: GEL Output: Module 10: SCR 0 (BR0/1/2/8) STATE = 3
C674X_0: GEL Output: Module 11: SCR 1 (BR4) STATE = 3
C674X_0: GEL Output: Module 12: SCR 2 (BR3/5/6) STATE = 3
C674X_0: GEL Output: Module 13: PRUSS STATE = 0
C674X_0: GEL Output: Module 14: ARM STATE = 0
C674X_0: GEL Output: Module 15: DSP STATE = 3
C674X_0: GEL Output:
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output: | PSC1 Information |
C674X_0: GEL Output: ---------------------------------------------
C674X_0: GEL Output:
C674X_0: GEL Output: State Decoder:
C674X_0: GEL Output: 0 = SwRstDisable (reset asserted, clock off)
C674X_0: GEL Output: 1 = SyncReset (reset assered, clock on)
C674X_0: GEL Output: 2 = Disable (reset de-asserted, clock off)
C674X_0: GEL Output: 3 = Enable (reset de-asserted, clock on)
C674X_0: GEL Output: >3 = Transition in progress
C674X_0: GEL Output:
C674X_0: GEL Output: Module 0: EDMA3CC (1) STATE = 0
C674X_0: GEL Output: Module 1: USB0 (2.0) STATE = 0
C674X_0: GEL Output: Module 2: USB1 (1.1) STATE = 0
C674X_0: GEL Output: Module 3: GPIO STATE = 0
C674X_0: GEL Output: Module 4: UHPI STATE = 0
C674X_0: GEL Output: Module 5: EMAC STATE = 0
C674X_0: GEL Output: Module 6: DDR2 and SCR F3 STATE = 3
C674X_0: GEL Output: Module 7: MCASP0 + FIFO STATE = 0
C674X_0: GEL Output: Module 8: SATA STATE = 0
C674X_0: GEL Output: Module 9: VPIF STATE = 0
C674X_0: GEL Output: Module 10: SPI 1 STATE = 3
C674X_0: GEL Output: Module 11: I2C 1 STATE = 0
C674X_0: GEL Output: Module 12: UART 1 STATE = 0
C674X_0: GEL Output: Module 13: UART 2 STATE = 0
C674X_0: GEL Output: Module 14: MCBSP0 + FIFO STATE = 0
C674X_0: GEL Output: Module 15: MCBSP1 + FIFO STATE = 0
C674X_0: GEL Output: Module 16: LCDC STATE = 0
C674X_0: GEL Output: Module 17: eHRPWM (all) STATE = 0
C674X_0: GEL Output: Module 18: MMC/SD 1 STATE = 0
C674X_0: GEL Output: Module 19: UPP STATE = 0
C674X_0: GEL Output: Module 20: eCAP (all) STATE = 0
C674X_0: GEL Output: Module 21: EDMA3 TC2 STATE = 0
C674X_0: GEL Output: Module 24: SCR-F0 Br-F0 STATE = 3
C674X_0: GEL Output: Module 25: SCR-F1 Br-F1 STATE = 3
C674X_0: GEL Output: Module 26: SCR-F2 Br-F2 STATE = 3
C674X_0: GEL Output: Module 27: SCR-F6 Br-F3 STATE = 3
C674X_0: GEL Output: Module 28: SCR-F7 Br-F4 STATE = 3
C674X_0: GEL Output: Module 29: SCR-F8 Br-F5 STATE = 3
C674X_0: GEL Output: Module 30: Br-F7 (DDR Contr) STATE = 3
C674X_0: GEL Output: Module 31: L3 RAM, SCR-F4, Br-F6 STATE = 3

Robert56682 said:

C674X_0: GEL Output: State Decoder:
C674X_0: GEL Output: 0 = SwRstDisable (reset asserted, clock off)
C674X_0: GEL Output: 1 = SyncReset (reset assered, clock on)
C674X_0: GEL Output: 2 = Disable (reset de-asserted, clock off)
C674X_0: GEL Output: 3 = Enable (reset de-asserted, clock on)
C674X_0: GEL Output: >3 = Transition in progress

Robert56682 said:

C674X_0: GEL Output: Module 3: GPIO STATE = 0

The GPIO peripheral is disabled.

Brad, I do setup both the PLL and DDR/EMIF during initialization. But both my application code does, as well as the simple led program that seems to work in stand-alone. Their both using a form of the OMAP-L128 supplied code/calls EVMC6748_init() and EVMC6748_initRAM().

So it's confusing why it's ok with the simple led program, but not my app code (although my app code is tweaked a bit for these functions).

But doesn't matter, if you have a strong sense this is the issue, I'll take them out and do the AIS route. Problem is that I don't know how to do it in AIS, probably a big learning curve. But better to start now, then when too late.

Hi 

Along with suggestions from Brad..

Since LED blink seems to be the criteria for pass/fail, can you also make sure that the PINMUX settings have not changed between how/when you do this with your application code in emulation mode, vs when you flash the application.

Perhaps you can sanity check with a register dump compare of pinmux registers between the 2 scenarios?

The program counter value from the debug gel file shows where your DSP CPU is currently executing from - does that give you any clue looking at your linker or map file as to where your code maybe?

Program Counter (PC) = 0x11822ECC

BTW this PC value says that you are executing from DSP L2 ROM, so the processor has definitely finished booting from the ROM etc. 

Regards

Mukul 

Brad Griffis said:

The GPIO peripheral is disabled.

Doh.  Yeah, that's a problem.  I've been trying to find out the reason, but no luck so far.  When I run the simple led program standalone, its value is 3 (enabled).  But their initialization should be almost identical at this point.  

Brad Griffis said:

One option would be to program that through HexAIS.

Will try anything at this point.  So disable the GPIO init in the program, and do explicitly via HexAIS?  Can you give me a few pointers on how to do it there?

It's documented within the ini file itself.  Here's a snippet:

; This section should be used to setup the power state of modules

; of the two PSCs.  This section can be included multiple times to

; allow the configuration of any or all of the device modules.

;           |------24|------16|-------8|-------0|

; LPSCCFG:  | PSCNUM | MODULE |   PD   | STATE  |

;[PSCCONFIG]

;LPSCCFG=

So you need to uncomment the last couple lines.. .  For example, something like this:

[PSCCONFIG]

LPSCCFG = 0x01030003

Brad Griffis said:

It's documented within the ini file itself.  Here's a snippet:

Any way to get the values from the emulator, after successful run?  I'd like to get all the psc, clocks, DDR, etc, without having to go through a big spreadsheet exercise to come up with the final value to put in the .ini file.

From what I can see, the GEL Output doesn't give these values either.

Mukul Bhatnagar said:

Perhaps you can sanity check with a register dump compare of pinmux registers between the 2 scenarios?

Hello,

I went through and dumped the pinmux, for the case when the leds work for my application under emulation, and then when they don't when running out of flash (flash, run, reconnect with emulator, look at registers).  And below are the before and after values.  I see that the GPIO5 appears to be  mux'd correctly, 0x8000.  However, under the not-working situation, there have been a lot of other values set in it, looking like they are related to SPI.  Some of the other pinmux registers have changed as well, between working and not working.  Can you have a look and comment?

Thanks,

Robert

PINMUX0	0x00080000	0x00080000
PINMUX1	0x00000000	0x00000000
PINMUX2	0x00000000	0x00000000
PINMUX3	0x00000000	0x00000000
PINMUX4	0x00002200	0x00000000
PINMUX5	0x00008000	0x00118110
PINMUX6	0x00000000	0x00000000
PINMUX7	0x00000000	0x00000000
PINMUX8	0x00000000	0x00000000
PINMUX9	0x00000000	0x00000000
PINMUX10	0x08000000	0x08000000
PINMUX11	0x00800000	0x00800000
PINMUX12	0x88888800	0x00000000
PINMUX13	0x00000080	0x00000080
PINMUX14	0x00000000	0x00000000
PINMUX15	0x00000000	0x00000000
PINMUX16	0x00000000	0x00000000
PINMUX17	0x00000000	0x00000000
PINMUX18	0x00000000	0x00000000
PINMUX19	0x00000000	0x00000000

Robert,

First, were you able to get GPIO enabled in the PSC using the ini change I mentioned?

Rather than going through these 20 registers bit by bit, I suggest we simply move in the direction of making them the same between the working and non-working application.  I wasn't clear which column was the "good" and which was the "bad".  However, I recommend simply adding 20 entries to the ini file along these lines:

; This section allows setting of a single PINMUX register.
; This section can be included multiple times to allow setting
; as many PINMUX registers as needed.
;         |------24|------16|-------8|-------0|
; REGNUM: |              regNum               |
; MASK:   |               mask                |
; VALUE:  |              value                |
;[PINMUX]
;REGNUM = 5
;MASK = 0x00FF0000
;VALUE = 0x00880000

[PINMUX]
REGNUM = 0
MASK = 0xFFFFFFFF
VALUE = 0x00080000

[PINMUX]
REGNUM = 1
MASK = 0xFFFFFFFF
VALUE = 0x00000000

Hi
I would agree with Brad
1) Please make sure you enable the GPIO module via PSC , as shown in Brad's email- your GPIO/LED toggling will not work if the GPIO module clocks have not been initialized. You should be able to do this via the AIS/HEXAIS or should take of it in your application code (if you were relying on the GEL file previously to enable PSC and setup Pinmux etc)
2) Please confirm which GPIO pin is being used for toggling the LED - it does appear that if you are using GPIO5, then the PINMUX12 register will need to be appropriately configured somewhere. The differences in PINMUX5 register values are ok, as it is essentially the ROM boot loader setting up the pins required for you to be able to boot over SPI1 flash.


Regards
Mukul

Brad Griffis said:

First, were you able to get GPIO enabled in the PSC using the ini change I mentioned?

As it turned out, the non-led flashing app code from flash did have the GPIO enabled, checked via the GEL file debug dump.  It must have been in the fog of war yesterday, that I had managed to flash in a version that didn't have it enabled.  But with the latest non-led flashing app code, which is back to my original, it does have a value of 3.  

C674X_0: GEL Output: Module 3: GPIO               STATE = 3

However, I will be getting it enabled via the PSC and ini change advised ASAP.

Brad Griffis said:

Rather than going through these 20 registers bit by bit, I suggest we simply move in the direction of making them the same between the working and non-working application.  I wasn't clear which column was the "good" and which was the "bad".  However, I recommend simply adding 20 entries to the ini file along these lines:

Ok, will do.  

 

Mukul Bhatnagar said:

it does appear that if you are using GPIO5, then the PINMUX12 register will need to be appropriately configured somewhere. 

There is a big difference between the emulator, working version (left most column) and the non-working flashed version (right column).  The value of PINMUX12 is much different.  In fact, it's 0 for the non-working case:

PINMUX12

0x88888800

0x00000000

Yes, they are. They are used to trigger the LED sequence! And I fixed an overlooked pinmux configuration (12), and it appears to be working!, i.e. the flashed application code is running the led sequencing stand-alone! Now, I've been at this for long enough not to declare victory quite yet, but at this time, that appears to break the log jam ;)

My application code is much more complex, I had just put the led sequencing at the start, for getting the flash run code to report back. I'll start to put the application code back together, to a final goal of all running out of flash. I'm optimistic at this point, though.

Thanks much Brad and Mukul.

I recognize the need to do some of the initialization from HexAIS, though, as you've advised. And will be doing that. Because of time pressures associated with a deadline, I have to make getting the full application code running stand-alone a higher priority (assuming it does, if not I'll be returning to that sooner). But I will be circling back next chance I get, to complete the HexAIS configuration, and share what I've learned about doing it here.

Hello,

I have remaining HexAIS questions, which are worthy of a separate thread. So I created this:

e2e.ti.com/.../542435

Any follow-up assistance there would be appreciated.

Robert