This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RE: CCS/OMAP-L138: UARTStdio and EMAC access using starterware

Other Parts Discussed in Thread: OMAPL138, OMAP-L138

Hi Rahul,

Ok that makes sense now... Many thanks.

I have two further questions that you could probably answer very quickly.

1/ is it possible to access the emac using starterware driver (lwIPInit) simultaneously from the ARM (instNum=0) and the DSP (instNum=1) ?

2/ Another issue is that I see that there is a clocking/baud rate issue when using starterware    UARTStdioInit() with the omapl128  DSP. Could you point me in the right direction to resolve this? The identical code works fine on the omapl138 ARM.

Best Regards

Andrew

  • Andrew,

    1. Yes, you can access EMAC using starterware lwIP APIs. I don`t think there is an example of simultaneous access in the package but from SOC perspective both the ARM and the DSP have access to EMAC.


    2. Inorder to change the clocking and the UART baudrate, you can refer to the clocking spreadsheet here:
    processors.wiki.ti.com/.../AM18xx

    Use the excel spreadsheet to simulate your clocks on PLL1 and then go the UART tab and select the correct oversampling and PRESCALE value to simulate the clock setup for required baudrate. The starterware assumes a 24 Mhz input clock and configures the baudrate to 115.2 kbps for STdandard IO. In debug mode, GEL files or PLL0Init and PLL1Init functions can then be called to set the PLL using the multipier and divider values. UART baudrate is setup in the file UARTConSole.c and uart.c files

    Regards,
    Rahul

    PS: since this is unrelated to the previous issue, I will split these e2e thread.

  • HI,

    Many thanks for the response. I have been looking at this problem for most of the day and have traced the code through the Uartconfigsetexpclk function for both the ARM (which works) and the DSP (that is corrupted) The settings for both are identical, 115200 and all the registers are configured with the same values. So I guess that the XDS200 emulator must be configuring the PLL differently for the ARM vs the DSP (both versions directly compiled from the starterware package)

    Is this what you would expect?

    Many thanks in Advance

    Andrew
  • Yes, that is a possibility. Can you specify how you are running the code on the DSP as in the sequence with which you connect to the device.
    Note, when you connect to the cores on the DSP, there are GEL files that perform the initialization or cores, clocks, PSC and DDR. ARM and DSP clocks on this device are essentially using the same SYS_CLK1 so if you are initializing the cores with GEL files this shouldn`t occur.

    Do you see the GEL running when you connect to the device? If GELs are populated on the ARM but not to DSP and you dirrectly connect to the DSP, then this could occur as the clocks will by default be running in bypass mode if the boot switches are set to No boot/emulation boot mode. you can confirm this by going into the register view and comparing the PLL0CTL registers in the boot configuration space.

    If you still are running into this issue, please let us know and I can provide further guidance .\

    Regards,
    Rahul
  • Hi Rahul,

    Many thanks for the information. I can confirm that the ARM is running the GEL file ..\..\emulation\boards\lcdkomapl138\gel\OMAP-L138_LCDK.gel. However, the DSP  is not running a GEL file when loading via the XDS200 emulator(nothing at the console). I have tried running the same GEL file under the target configuration for the C674x put it stops with multiple errors in the console window.

    Any guidance would be greatly appreciated at this stage in my learning process.

    Best Regards

    Andrew