• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 813 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.

CCS/IWR6843: Custom PCB will not load programs

Peter A
Intellectual 255 points
Part Number: IWR6843
Other Parts Discussed in Thread: , MMWAVEICBOOST, UNIFLASH, IWR1443

Tool/software: Code Composer Studio

Hi, 

We've had some custom PCBs fabricated based on the IWR6843. The design is basically a stripped back version of the IWR6843ISK and MMWAVEICBOOST, and runs with the XDS110 debugger. We are however having some problems with running the demo codes on the devices. I'll attempt to summarise what we've achieved and what the problems are, and what we have tried so far. 

Procedure so far:

  • First flashed the XDS110 debug firmware onto the virgin TM4C1294xxxx - this runs fine, both the USER UART and DATA ports show now in device manager. 
  • Next placed the device into flashing mode (we have used a similar header pin arrangement), and flashed xwr68xx_ccsdebug.bin through uniflash. This runs fine and program load is successful
  • Placed the device in functional mode and opened CCS (power cycled and reset). 
  • Built the mmwave demo
  • Created a new target configuration
  • Run "test connection" which outputs a successful JTAG test. 
  • Launched the new target configuration and connected to the Cortex_R4_0
  • Attempted to load the built .xer4f file
  • We then recieve the following error: 
    Cortex_R4_0: File Loader: Verification failed: Target failed to write 0x0000000

I have checked and re-checked the routing and schematics - there doesn't seem to be an error here. All the voltages appear to be fine, the oscillator outputs a clean 40 MHz signal and the various pull-ups and pull-downs are present. Supply is a 5V 3A supply and the USB cable is fine. The fact that the device flashes in uniflash seems to confirm that a hardware error is hopefully not the problem at this point.

I am using the most up to date SDK (3.2) but have also tried with 3.1

I have also tried flashing the xwr68xx_mmw_demo.bin and running the online visualiser, but this also doesn't work. (it connects, but the config file doesn't send). 

I have also tried loading the pre-built .xer4f but that doesn't work either.

I am suspecting that there is something different that needs to be done to new IWR6843 chips that I have missed. 

I have tried the solution found here: https://e2e.ti.com/support/sensors/f/1023/t/789574#pi320995=1 , (editing the R4F linker file) but have not been successful. I get the following error: Cortex_R4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. 

I am not sure if I have missed a step in there somewhere, if we need to follow a different procedure for new chips. Hopefully you'll be able to point me in the right direction. 

Many thanks, 

Peter

  • 0
    TI__Mastermind 25835 points
    Hello,

    Could you please tell us which flash part is connected on the board?

    Thanks and regards,
    CHETHAN KUMAR Y.B.
  • 0 in reply to CHETHAN KUMAR Y.B.
    Intellectual 255 points

    Hi Chethan

    We have a MX25R1635FM1IL0 on the board, the same as what we have used on a previous iteration of the board (although that was with a 1443 device) 

    Peter

     

  • 0 in reply to CHETHAN KUMAR Y.B.
    Intellectual 255 points
    Just to add to this - We also have the ERR_OUT light illuminated on the boards - this is there only in Functional mode (SOP2) removed and not in Flashing mode. I can't find any hardware errors so is this just because it is not asserted in the code? (because there is no code)

    Not sure if this indicates anything else to you.

    Peter
  • 0 in reply to Peter A
    Intellectual 255 points

    Just wondering if you have any ideas as to what could be causing this issue. Some further tests that I have done: 

    I have tested the current draw of the board - its reading 290mA in functional mode. We are using a 5V 3A supply, so I don't think that's a problem. 

    I've tested the clock on a scope and its fine @ 40MHz. I can also see during the flashing process that there is communication with the QSPI flash on the scope. However once in functional mode the QSPI lines are either 0V or 3.3V if they have a pull-up. 

    I have also read and tried the details in this post: https://e2e.ti.com/support/sensors/f/1023/t/796375. Following this procedure allows the program to load, but then it fails to connect to the DAP, with the error I previously mentioned. 

    I am using the new SDK V3.2 but  have also tried V3.1. 

    I've also tried flashing both my own generated mmwavedemo.bin file and the mmwavedemo.bin file included in the SDK, and running the visualiser online but with no success. The program loads fine in uniflash, i remove SOP2, power cycle and reset, then launch the visualiser.  It connects to both ports, then the DATA port sits there "waiting for data", while the CFG port is connected. 

    I've also tried different versions of uniflash, but this makes no difference. We have a number of custom boards, all with the same problem. Our MMWAVEICBOOST and IWR6843ISK work perfectly. 

    Please let me know if you have any further tests I could make to establish what the issue could be.  

    Many thanks in advance, 

    Peter

  • 0 in reply to Peter A
    TI__Mastermind 25835 points
    Hello,

    From the above signature it appears to be boot loading problem from the external QSPI flash.
    ROM bootloading seem to be fine in the flashing mode, hence you don't see NERROR out put.

    Could you please use the same flash that was used in the EVM MX25V1635FZNQ?

    Thanks and regards,
    CHETHAN KUMAR Y.B.
  • 0 in reply to CHETHAN KUMAR Y.B.
    Intellectual 255 points

    Hi Chethan, 

    Thanks for the reply. Just as I received your message, I finally managed to get it working. The problem, as you suspected was with the flash memory. It turns out that the MX25R1635FM1IL0 is by default in low power mode (the "L" in the part number signifies this). This sets the frequency to 33MHz. This worked fine on our IWR1443 ES2.0 silicon boards because (correct me if i am wrong) they were able to operate with a slower 33 MHz flash, but this is not the case for the newer IWR6843 chips. 

    After reading the flash selection guide carefully, which I should have done in the first place, I realised that we needed to change the flash to one that operates at greater than 40 MHz. I took an old SPANSION S25FL132K that I had on another board to test it out, and now everything is fine, and the error light is no longer there. Changing the memory addresses etc. is not necessary. I'll replace the rest with MX25V1635FM1I which i believe should be fine. 


    That will teach me to read datasheets and app. notes properly in future! 

    Thanks, 

    Peter