UART operation in Direct Boot Mode

Can you determine if the garbage is sent out in response to your UART0 initialization code or if it starts before that? You could put in a long delay prior to the initialization code to find that out. Or try running the same code from RAM in No Boot mode from the emulator, but be sure to remove the GEL file or at least get rid of any initialization from the GEL file, such as in the OnTargetConnect function.

Do you have software anywhere that sets VDD3P3V_PWDN = 0?

Thank you guys.  It's working now.

It was only spitting out the garbage when I tried to transmit from the UART after my initialization code (I removed my transmit code and I didn't see any garbage to be sure it was my code causing it).

VDD3P3V_PWDN was being set (by the Spectrum Digital BSL EVM6424_setupPinMux function).

The issue was as Brad pointed out my usage of the CSL register macros on write only registers.  I just set the values in those registers and it's working now.  I do like the CSL macros for code clarity but I'll watch out for this in the future.

Thanks!

Excellent job getting it working. And thank you for letting us know..

There are other CSL macros that you may find more practical for some cases and still give you the code clarity. The example below will run significantly faster than the CSL_FINST macros, although speed is usually not an issue during configuration.

    /* Enable FIFO mode, leaving reset values in other fields */
    uartOvly->FCR =
                    CSL_FMK (UART_FCR_RXFIFTL, 0) ||
                    CSL_FMK (UART_FCR_DMAMODE1, 0) ||
                    CSL_FMK (UART_FCR_TXCLR, 0) ||
                    CSL_FMK (UART_FCR_RXCLR, 0) ||
                    CSL_FMKT(UART_FCR_FIFOEN, ENABLE);

    /* Set Rx trg lvl, DMAmode, clear Tx & Rx FIFOs */
    uartOvly->FCR =
                    CSL_FMKT(UART_FCR_RXFIFTL, CHAR4) ||
                    CSL_FMKT(UART_FCR_DMAMODE1, ENABLE) ||
                    CSL_FMKT(UART_FCR_TXCLR, CLR) ||
                    CSL_FMKT(UART_FCR_RXCLR, CLR) ||
                    CSL_FMKT(UART_FCR_FIFOEN, ENABLE);

I am not sure why you are disabling the DMAMODE1 bit. It should always be written as 1 per the UART User's Guide.

Thanks.  Yes the CSL_FMK macros will improve code clarity v.s. just setting the hex values.

As for the DMAMODE1 bit in FCR, if I'm not using EDMA transfers why does this have to be set?  I know spruen6c.pdf says:

"DMA MODE1 enable if FIFOs are enabled. Always write 1 to DMAMODE1. After a hardware reset, change DMAMODE1 from 0 to 1. DMAMOD1 = 1 is a requirement for proper communication between the UART and the EDMA controller. 0 DMA MODE1 is disabled. 1 DMA MODE1 is enabled."

But why send the events to the EDMA controller if I'm using programmed I/O?

UART User's Guide said:

Always write 1 to DMAMODE1.

You do not always get direction this clear. The statement of the intended function of the DMAMODE1 bit for EDMA communication adds confusion for a case like yours where you will not be using EDMA. But it does not say to write 1 do DMAMODE1 only if you are using EDMA, it says to always write 1 to DMAMODE1.

If it hurts your operation with programmed I/O, then please report that to this forum. But if you do not find a negative impact, please write 1 to this bit so you will minimize the chances of problems in the future. I doubt it will hurt your operation, though.

"The statement of the intended function of the DMAMODE1 bit for EDMA communication adds confusion for a case like yours where you will not be using EDMA."

Indeed, it does add confusion.  The trouble is, that the confusion it adds is such that even a TI employee with "guru" status is not really sure how it will affect programmed I/O.   I would really appreciate it if someone can dispel this confusion, to make sure this will not introduce some hidden bug in our system.

So...5 years have passed, and I am just wondering if there is now a clearer answer.  I see three possibilities:

1) For programmed I/O, the DMAMODE1 bit should be 0, or at least can be 0 with no problems caused

2) For programmed I/O, the DMAMODE1 bit must be 1, and as a result, it will send signals to the EDMA controller, but you do not have to worry about this

3) For programmed I/O, the DMAMODE1 bit must be 1, and as a result, it will send signals to the EDMA controller, and to make sure this does not cause problems, you have to make sure of the following:  (TI guru, please fill in the blank)

Actually, the best answer would be an exact explanation as to why or when the DMAMODE1 bit must be 1....and if it must always be 1, why not just build it that way in hardware, or at least have that as the reset value?

DMAMODE1 relates to the timing of the DMA event generation.  A value of zero corresponds to single-character transfer mode.  A value of one corresponds to the multi-character mode.  Only multi-character mode is validated, tested, and supported and so therefore we say to always write one to the bit.

Michael Greenspan said:

2) For programmed I/O, the DMAMODE1 bit must be 1, and as a result, it will send signals to the EDMA controller, but you do not have to worry about this

This is mostly correct (i.e. it is the most accurate of your 3 statements).  With DMAMODE1 = 1, the UART will send events to the DMA if the FIFO is enabled when the programmed threshold is reached.  If you're not using DMA then none of this likely matters all that much.  The main point here is that we require you to use the device in a mode of operation that has been validated and tested.  So whether you're using DMA or not, you must set this bit.

Thanks.