UART Reset debugging

[jasonhendrix]

We are developing a custom board with the LS1020a chip and an N25Q256 QSP flash from which we will boot u-boot. In preparation, I am using the  LS1021ATWR to prepare for initial integration - which involves loading u-boot and RCW into flash and debugging u-boot.

I used CW flash programmer to load the RCW and U-boot onto the dev board's QSPI flash.  This works - on power-up the board boots to the u-boot command line (I can see that it is my code by board name and version string).  The command line and u-boot functions are fully functional at this point.

Now, when I try to debug (using the several references from NXP for debugging u-boot), a couple of strange things happen:

1.  When I connect, PC = 0; I kind of expected it to be in DDR where it runs U-Boot.  I believe this was the case when I debugged u-boot from NOR.

2. The RCW registers in DCFG_CCSR are wiped out

3. The UART output and input are garbage

I can perform the reset from CW, but the above conditions still hold.  I guess that the debugger is resetting the DSP, though I've disabled all reset and initialization I can find in the connection/launch configuration.

The reset doesn't really bother me (though it requires that I manually keep my jtag init file synchronized with actual RCW code).    The big problem is the UART - does anyone have any ideas about what happens to the UART during debug attach/reset?  I suppose it could be a clocking issue as well.  Everything else seems to be running OK - the code relocates to DDR and is servicing the console, but incoming and outgoing data is garbage.

[jasonhendrix · Accepted solution]

Was able to get the configuration setup properly and after a cycle of CW, it worked.  Answer described in this thread:

SYS_PLL_RAT and PLLPGSR

[jasonhendrix]

The problem is with the clocking.

I was able to check the platform clock using TP3 on the LS1021ATWR dev board.  I first set the CLKPCSR fields to output the platform clock (CLKOSEL = 0x1B).  It was running at 200MHz.  I also set CLKOSEL to 0x1E to check SYSCLK.  It was running at 100MHz, but not a very nicely shaped wave.  I then calculated my baud rate divisor based on this 200MHz value and I have serial comm.  So I seem to have a problem with clock configuration.  Again, only after connecting with JTAG.  When running from power-up it's fine.  I've started another thread here sorta related to that:

SYS_PLL_RAT and PLLPGSR

[addiyi]

Did you take a look on U-Boot Debug using CodeWarrior for QorIQ LS series – ARM V7 ISA ?

When using the attach launch (with no init file and without reset the target), then you should see the PC correctly (DDR if the uboot is already relocated in DDR).

Adrian

[jasonhendrix]

A couple of more things - I've tried both Minicom and PuTTY on the host side.

If I set the internal loopback register in MCR, then I can write to THR and see the same value in RBR.  But, if I disable loopback, I don't get the expected data,  I get data with a lot more bits than I expect.  E.g. 0xFF03 instead of 0x65

Neither TX nor RX are working right.

These items make me  wonder if the mbed UART/USB converter chip is having a problem.

[jasonhendrix]

Yes, I've used AN4956, AN4876, and the doc by luminliang.   All were helpful in getting me going.  I'm able to step through code before and after relocation.  Now that I've switched to QSPI boot, I've been able to step through code before and after relocation.  There's just the problem of the UART data and the possibly related "reset" symptoms when attaching.  I'll try to figure out what's going on with the UART.  When I boot to prompt, I can dump the UART registers and see 00 00 c1 03 03, or something like that.  When I step through the code, I can see those values in the register view after uart init.  That's what makes me wonder if it's a clock configuration problem. 

I may also try removing the JTAG initialization file.  Maybe that's causing some sort of reset.