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/RM48L952: Programming error using XDS100v2

Part Number: RM48L952


Tool/software: Code Composer Studio

Hi Champs,

My customer is using RM48L952 in their product. XDS100v2 and CCS can program RM48L952CZWTT(Rev C) successfully, while programming RM48L952DZWTT(Rev D), several errors appears as follows. And XDS100v2 can connect to the device successfully.

Would you kindly suggest where the problem comes from?

Thanks.

BR,

Young

  • Hi Young,

    This could just be a board issue like bad soldering. There isn't any reason that a rev C or D would behave differently to the emulator.

    The 'Test Connection' button when opening the target configuration file will run some diagnostics to see if the JTAG path is good.

    If this passes then the JTAG path is good but some other problem like RESET being held low or some other critical signal being open/shorted might be the problem.
  • Hi Anthony,

    Thanks for your reply.

    I will ask customer to check their hardware.

    BR,

    Young

  • Hi Anthony,

    Customer sent the schematics about JTAG. After removing the 0 Ohm resistor(R51A) between Warm Reset(nRST) and JTAG test hardware reset(TRSTn) on PCBA using RevD, RM48L952 can be downloaded correctly.

    On their PCBA using RevC silicon, nRST and TRSTn were connected together using 0 Ohm resistor, but the device still can be programmable. 

    So customer is asking why RevC can work well, while RevD cannot? And should nRST and TRSTn be connected together?

    Thanks.

    BR,

    Young

  • Ok, I can't answer exactly why the silicon revs are different but you shouldn't connect RST\ to TRST\ anyway.
    Because any reset on the chip will then reset JTAG which will break the emulator connection.
    So if it works it is 'luck'.

    There is an SRST\ pin on the XDS100v2 that can be connected to a board-level reset although power on reset is preferred for this.

    There really is no reason to drive the RST\ pin because this warm reset can be driven through scanning the IcePick