• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 874 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

Can't get the AM3505 ASIC ID using FlashTool V1.6 through UART3

AM3505: ASIC ID on UART3 is incomplete - only a few bytes transmitted

Fraser Lawson1
Prodigy 240 points

Part Number: AM3505

Background. - We are running up an AM3505AZCN on a new prototype pcb. The design is very much the same to a previous design, with minimal changes.

Problem - to boot from UART3 we assert SYSBOOT5 ("Bootmode") to logic 1 then pulse SYS_NRESPWRON "Pwr_ON_RESET_N).

On release of reset (SYSBOOT 5 still logic1) we see a small burst of data on UART3 - only about 3 bytes. On our previous design we see a large burst of approx 60-70 bytes.

It appears that the ASCI ID begins to transmit then aborts?

Things we have verified are correct: 

  • The Power supply power-up sequence (although it was initially incorrect - now fixed)
  • 26MHZ clock
  • 32kHz clock
  • SYS_NRESPWRON
  • SYSBOOT(8:0) = 001110101 when we assert bit 5 to logic 1

Is there any reason(s) why the ASIC ID transmission would "abort"? 

Please advise on what else we should check next.

Thanks in advance.

  • 0
    TI__Intellectual 2180 points

    Hello,

    Are you using an RTOS or Linux?

    Thanks,

    Max

  • 0 in reply to Max Kross1
    Prodigy 240 points

    Hello, Max.

    We are using neither at present - we have not progressed this far yet.

    This is the first "bring-up" of a new prototype PCB - we haven't managed to load anything in yet, since the ASIC ID does not work correctly.

    Thanks,

    Fraser

  • 0 in reply to Fraser Lawson1
    TI__Guru* 95831 points

    Fraser, are you able to connect via JTAG on your board?  This will help give an indication of the state of the processor.  Also check power rails and system clock during the first few UART transactions.  Once the UART transactions have started, i can't think of any reason why it would abort other than a power or clocking issue.

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 240 points

    Hello, James.

    Thanks for your response.

    I will need to add some "DNI" parts to connect via JTAG. But in the meantime I've attached some scope/logic analyser waveforms of the relevant power supplies, clocks, reset and sysboot(5:0) during normal power-up. (To get the bootloader in, we assert SYSBOOT5 then Reset. On release of reset then SYSBOOT5 we should see the ASIC ID on the CPU TX - but don't.)

  • 0 in reply to Fraser Lawson1
    TI__Guru* 95831 points

    Hi Fraser, thanks for the scope shots.  I can see from these that most likely the main source of the problem is that the system clock (SYS_XTALIN) starts up after NRESPWRON rising edge.  The system clock needs to be oscillating and stable before rising edge of power on reset (see figure 5-3 of the datasheet).  The SYSBOOT signals are latched and the ROM will attempt to run at power on reset rising edge, but these will not happen without the clock present.

    Regards,

    James 

  • 0 in reply to JJD
    Prodigy 240 points

    Hello, James.

    Thanks for your support.

    Sorry for the delay in replying.

    We took your advice and shifted the SYS_XTALIN to start up well before the NRESPWRON rising edge (although it had worked on a previous design - then we used the SYS_CLKREQ output to enable it).

    In itself, this did not solve our problem.

    However, when we connected our programming adapter we realised we had an indeterminate logic level on the UART_RX pin (due to the voltage divider effect of our pull-down resistor with the series resistor in the programming adapter).

    Once we increased the value of our pull-down resistor in UART RX, then the ASIC ID transmitted successfully.

    My best guess at this time is that somehow, the indeterminate logic level on the UART RX pin was causing unpredictable behaviour in the UART logic that prevented complete ASIC ID transmission?

  • 0 in reply to Fraser Lawson1
    TI__Guru* 95831 points

    OK, i wasn't expecting that since the previous board was working.  The pull down resistor on your board most likely is in conflict with an internal pull up that is configured by the ROM.   The internal pull value can vary from part to part, and thus i think you are on the right track with your assumption:  Your board pull down was most likely either overriding this (pulling RX low instead of high when not driven), or creating a voltage divider and producing a mid-level voltage. 

    Regards,

    James