Processor Hangs in SPL or U-Boot

Great! You made everything to determine the source of trouble, but the last step:

If the firmware crashes at writing to periferal registers then most probable is something wrong is about respective power domain or domain reset. This is trivial but you did not say anything about what the domain voltage is and what is the reset state.

Thanks for the response, but I'm not sure how to determine the state of the domain voltage and the reset state? Is there there a register I should read or test point voltage that I should measure? 

As near as we can tell we've removed the modifications that were done to disable the RTC and our EE says that the voltages rails look good. 

Thanks,
Matt S.

It looks like the GPMC module is part of the Core Power domain so I've tried to check the relevant registers:

CM_MPU_CLKSTCTRL = 0x6

CM_MPU_MPU_CLKCTRL = 0x2

CM_PER_GPMC_CLKCTRL=0x2

These values all look ok.
I've also taken a look at many of the PER_* registers and I haven't found anything glaring but I don't fully know what I'm looking for.

I have determined that when it crashes it's a Data Abort exception when it writes any of the GPMC registers. I've tried changing the GPMC_SYSCONFIG register to 0x8 via the JTAG and CCS register window and it seems to work fine but as soon as I run the code to write the register I get the Data Abort exception.

I'd really appreciate a little more clarification on what I should be looking for here.

Thanks,
Matt S.

Hi Matt,

I just shared my experience on the case. The bootloader crashes on register accessing if there is no power (hard or soft switched off), or no clock.

Sorry, in these cases JTAG access fails also: register could not be properly viewed/written. No better idea.

You said you modified the code. If I were you, in such a case I'd reverted the modifications, and after insuring everything works, made modifications by smaller parts.

We didn't modify the code we modified the board, our EE made the modifications to disable the RTC per the TRM and we think that is when it stopped working. He has reversed all of his modifications but it's still not working.

It could be that he did something wrong and just broke it, I was just hoping that we could figure out what happened. 

It does seem strange that I can modify the register via JTAG but the software throws a Data Abort on the same change. Smells like the MMU is messed up or something. 

Thanks for the help, 

Matt S. 

So just to follow up on this, it turns out that the problem is something has gone wrong with the DDR2 memory. I didn't realize this until I got the JTAG debugger up and running and single stepped through each assembly instruction and realized that when it was attempting to write to the GPMC registers it was actually writing to 0x0 because the generated assembly code was storing the address of the register into memory and then reading it back out and both the reading and writing were failing and just producing zeros. 

I do find it kind of surprising that this is the first place in the SPL code to use the DDR2 memory. Might be worth adding an "optional" quick memory check, just after the SPL initializes it. 

Once I realized this I ran the DDR memory test scripts in CCS and sure enough they failed. I don't know what has happened to the DDR2 memory, perhaps we zapped it by mistake or one of our mods affected one of the traces on the board, I don't know. 

Matt S. 

Aha, sounds reasonably. 

There is a wide spread opinion that the DDR is not used at boot time. You proved once again that it is not always so.

Well the DDR certainly shouldn't be used until it's initialized. The code that was failing for me is after the DDR initialize function has been called. I did wonder how they ensure that the DDR isn't used until after it is initialized but I haven't looked into it. 

Matt S.