• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 31 subscribers
  • Views 717 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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:

AWR1443: AWR1443

AWR1443: Issue with booting the AWR1443 custom board

Anojh kumaran Rajendra
Prodigy 85 points
Part Number: AWR1443
Other Parts Discussed in Thread: UNIFLASH, , , IWR1443, IWR1443BOOST

Hi,

I have developed a custom board based on AWR1443BOOST. when i try to flash the device with uniflash (demo firmware from mmwave sdk), it completes successfully.

But when i change the SoP back to Functioning mode, it doesn't start. I also tried to flash the debug firmware (firmware from mmwave sdk) and debug, but CCS throws (Error -1170 @ 0x0)

After flashing all the firmware, NERROR_OUT is high. does it indicate anything about the firmware functionality?

  • 0
    TI__Mastermind 23855 points

    Hello Anojh,

    Is it possible to provide your schematic? How is NRST being controlled on power up?

    Regards,

    Adrian

  • 0 in reply to aozer
    Prodigy 85 points

    Hi,

    I have closely followed the reference design provided by the TI. I have two AWR1443 devices on one board and both the NRSTs are pulled up by a 10k resistor.

  • 0 in reply to Anojh kumaran Rajendra
    TI__Mastermind 23855 points

    If you manually assert the reset after power on to latch the SOP mode, does this make any difference?

    Regards,

    Adrian

  • 0 in reply to aozer
    Prodigy 85 points
    Hi Adrian, Thanks for your reply I have tried manually asserting the reset switch after power up and it didn’t make any difference 1. What conclusion can I make from the firmware being successfully written to the flash ? 2. I checked the qspi data and clk lines when the board is powered up in function mode. I can see some data is being transferred. Can I assume that the boot loader has successfully written the firmware to flash and it’s being fetched during normal power up ? 3. I checked all the voltages around the awr1443 and it seems fine as I have compared it with an awr1443boost evil board. The 40MHz clock peak to peak is slightly below 1V. Do you think it will be s problem ? 4. I receive some data via the bss logger. I read that is used for TI debugging. Will you be able to help if I pass you the bss log. Cz from what I received, I note that the working awr1443boost and my custom board are giving two different types of data in the bss log. 5. Does the radio subsystem contain another R4 core ? If so how does it get programmed ? Can you explain why the ES 2.0 and ES 3.0 have two different flashing procedures. Thanks, Anojh
  • 0 in reply to Anojh kumaran Rajendra
    TI__Mastermind 23855 points

    The clock voltage shouldn't be an issue. It is difficult to make any sound conclusions without seeing the full schematic. Would it be possible for you to send me the full schematic? You can send me a friend request and then I can provide you my email and you can send it via email for privacy. 

    You can attach the two BSS logs here, it could be helpful. 

    The flashing procedure changed from ES2 to ES3 because the MSS and BSS image were combined into a single meta-image. Which SDK version are you using? I am assuming the device on your board is ES3?

    Regards,

    ADrian

  • 0 in reply to aozer
    Prodigy 85 points

    Hi Adrian,

    Thanks for your reply.

    I'm attaching the full schematic here. I will attach the bss logs tomorrow as i don't have it with me now.

    I'm using an ES3 device.. The block diagram will indicate 4 awr devices. but two of them are in one board !

    WS1443.pdf

  • 0 in reply to Anojh kumaran Rajendra
    TI__Mastermind 23855 points

    The PDF isn't able to load for me. Can you send again? If not, we may have to exchange via email so you will need to send me a friend request.

  • 0 in reply to aozer
    Prodigy 85 points

    Hi Adrian,

    Sorry we are in two different time zones ;-)

    I have sent you a friend request btw ! my mail is anojhsna@gmail.com. you can also send a mail so that i can share the schematics with you 

    1) I tried to manually assert the reset pin again and it seems the oob demo is able to start. 

    but i get the below error during sensorStart command :

    mmwDemo:/>sensorStop
    Done
    mmwDemo:/>
    mmwDemo:/>flushCfg
    Done
    mmwDemo:/>
    mmwDemo:/>dfeDataOutputMode 1
    Done
    mmwDemo:/>
    mmwDemo:/>channelCfg 1 1 0
    Done
    mmwDemo:/>
    mmwDemo:/>adcCfg 2 1
    Done
    mmwDemo:/>
    mmwDemo:/>adcbufCfg 0 1 0 1
    Done
    mmwDemo:/>
    mmwDemo:/>profileCfg 0 77 7 7 130.05 0 0  27.96 1 512 4195 0 0 36
    Done
    mmwDemo:/>
    mmwDemo:/>chirpCfg 0 0 0 0 0 0 0 1
    Done
    mmwDemo:/>
    mmwDemo:/>frameCfg 0 0 1 0 500 1 0
    Done
    mmwDemo:/>
    mmwDemo:/>calibDcRangeSig 0 -5 5 32
    Done
    mmwDemo:/>
    mmwDemo:/>guiMonitor 1   1 0  0 0  1
    Done
    mmwDemo:/>
    mmwDemo:/>sensorStart
    Debug: Init Calibration Status = 0x7fe
    Error -1


    2) And i noticed that im trying to compare with IWR1443BOOST and my custom board (AWR1443). is there any specific changes in the BSS firmware for AWR1443 and IWR1443 ? is the error is because of BSS firmware inconsistency?
  • 0 in reply to Anojh kumaran Rajendra
    TI__Mastermind 23855 points

    Hello Anojh,

    Do you know what exactly you did differently to make it besides toggling the NRST?

    The firmware is identical for IWR vs AWR. The only difference would be if it is a different silicon revision, i.e. ES2.0 vs ES3.0.

    I suspect this is a hardware issue.

    Regards,

    Adrian

  • 0 in reply to aozer
    Prodigy 85 points

    Hi Adrian,

    Thanks for your reply!

    In the custom board, there were few resistors and capacitors which I removed. but I don't think that would have made any difference

    Below are the changes referred to the PROC010B TI ref schematics (My custom designators are different from the PROC010B TI ref schematic)

    1.  Initially, both the AR_MSS_LOGGER and AR_BSS_LOGGER lines were shorted together at the XDS110. I removed the AR_BSS_LOGGER connection (R135)

    2. I removed the AR_SCL and AR_SDA 0 ohm resistors at the AWR1443 (R197, R198)

    3. I removed the AR_RS232TX, AR_RS232RX  0 ohm resistors at the HD connector (R33, R21)

    4. I removed the decoupling capacitor at the AR_VOUT_PA (C83) 

    5. Changed RBIAS resistor at the XDS110 to 4.87k (R194) 

    I can recollect the AR_BSS_LOGGER output. but can you tell me the Baudrate cz what I get in putty is not completely readable. So I can collect it as .log file and share it to you 

    Thanks,

    Anojh

  • 0 in reply to Anojh kumaran Rajendra
    Prodigy 85 points

    Hi Adrian,

    I flashed the high accuracy ranging demo with activating only one channel (Tx-Rx pair) at a time and i can get the range profile. 

    I tested this for all the Tx-Rx pairs and it seems fine. Still, no idea why the sensorStart is not working for OOB demo

  • 0 in reply to Anojh kumaran Rajendra
    TI__Mastermind 23855 points

    Hello Anojh,

    I was able to open your schematic in Edge, so I will look over it. 

    Can you try a similar test with the OOB demo, load a custom profile with only a single TX/RX pair enabled? 

    If the high accuracy demo is working, this indicates that at least the UART, QSPI flash, and SOP pins are functioning as expected. I would expect that the OOB demo would also be able to work, as these are the primary dependencies for that demo as well.

    Regards,

    Adrian

  • 0 in reply to aozer
    Prodigy 85 points

    Hi Adrian,

    Thanks for your reply!

    I actually tried enabling single TX-RX pairs with the OOB demo and it didn't work. it throws 0x7fe and error -1. The other problem is, im not able to debug in CCS. it throws (Error -1170 @ 0x0).

    I will try to run the OOB demo again and verify. I might be able to use the cli_write function to debug where the error -1 is occurring.