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.

NHET GIO, Not working when debugging, working OK without the debugger.

Other Parts Discussed in Thread: TMS570LS3137

When the software is debugged it was noticed that NHET controlled GIO output pins were not functioning as expected.

After initialisations, the value of all the NHET registers was ALL 0x00000000

 

 

Other peripherals are working OK (GIOA, I2C )

Since the first register should never be zero, it was instantly suspicious that the NHET was not working. (in reset, or similar)

 

After a power cycle the GIOs work as expected, so the problem was artificially generated by the debug environment !?!

Any ideas?  Many thanks, Mike

My Environment is as follows :

TMS570LS3137 CZWT

CCS 5.2.0.00069 (Win 7)

XDS200 USB  (Spectrum Digital)

  • Mike,

    Can you check the device memory map setup in the debugger? This could prevent the debugger from reading from and writing to memory locations if these locations are not defined as writable "RAM" locations in the device memory map. The memory map is usually defined on "target connect" and is configured via the default gel file that is included.

    Regards,
    Sunil
  • I can set the NHET pin by writing to memory address in Memory window Address 0x FFF7 B854  (N2HET1 DOUT)

    Write 0x 00 00 00 02 makes N2HET1[1] Pin go high   < However the memory wind remains showing 0x 00 00 00 00 >

    Write 0x 00 00 00 02 makes N2HET1[1] Pin go low   < The memory wind remains showing 0x 00 00 00 00 >

    So it is working but the memory space is seemingly NOT readable.

    However doing the same thing via the Register window, does not set or clear the pin.

    I never have any trouble setting / or seeing the register values for the GIOA peripheral.

    I have checked the tms570ls3137.gel is available on my PC and it is binary the same as on another PC so not corrupt.

    Is there a way to get CCS to dump out the memory map in use?

    Could the NHET itself be disabling the READ access on the registers?

  • It looks like the clock to the N2HET module is disabled via the PCR registers. Try setting all bits in the PSPWRDWNCLR2 register at address 0xFFFFE0A8. The two N2HET modules are on peripheral select number 17.

    I will check the default gel file for LS3137 and see if there is anything wrong causing issues reading register values.

    Regards,
    Sunil
  • While CCS is connected to the target, you can view the memory map by clicking Tools --> Memory Map.
  • Thanks, I did that and N2HET1 comes up as;

    So CCS should be able to READ and WRITE to this section of memory

  • Thanks Sunil,

    I tried setting 0xFFFFFFFF to 0xFFFFE0A8 (PSPWRDWNCLR2)
    When I hit return to set all bits, the emulator then returned all bits in the register view back to be 0x00000000 (was this before the test)

    N2HET1 registers still are all viewed as 0x00000000

    N2HET1 writes are correctly setting pins.
    However it is not possible to read the status of the resisters N2HET1 registers always readback all zeros.

    I checked the above twice... once using Register View and once with Memory view.

    Could the NHET processor be stopping the readback? We are not running any code.

    Could the XDS200 be introducing this Error?
  • Mike,

    The NHET does not block a read back of the registers. I do not see this issue on my setup here using an xds100v2 emulator. I will try using an XDS200 and let you know.

    Regards,
    Sunil
  • Hi Sunil,

    After 2 days heavy debugging we found the problem

    The software was (Wrongly) clearing CLKCNTL to 0x 0000 0000 prior to setting 

    VCLK2R to 1 (Divide by 2)

    VCLKR to 1 (Divide by 2)

    [ PENA was still set to 0 ]

    We are running HCLK at 140MHz.

    So I think the issue was caused by the NHET not liking getting clocked over 100MHz for a small duration. This was enough to stop RAM reads from working.

    After this has happened the Microcontroller seems to need a power cycle before correct operation is restored (With corrected software)

    Many thanks for all the Help !!!

  • Hi Mike,

    That's great. That was another register that I was going to ask you to check, but then you indicated that there was no code running in the part. Glad it is working for you now.

    Regards,
    Sunil