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.

TMS570LS1224: ADG1MAXCOUNT interaction with G1_END field in ADG1INTFLG

Part Number: TMS570LS1224
Other Parts Discussed in Thread: TMS570LC4357, TMS570LS3137, HALCOGEN

We have determined there is an unexpected intermittent (probably timing related) interaction with the G1_END field in ADG1INTFLG when reading the ADG1MAXCOUNT register.

Repeated tests have confirmed that reading the ADG1MAXCOUNT register, will on occasion, clear the G1_END field in the ADG1INTFLG register.

The application does not have Enhanced Channel Selection Mode enabled but it is periodically checking that the ADG1MAXCOUNT register remains with the 'value after reset' as part of a status check of the ADC module registers.

As far as we can determine, there is no mention in the Technical Reference Manual (SPNU515C) that this register should not be read if Enhanced Channel Selection Mode is not enabled.

  • Hi Paulo,

    You are correct, G1_END bit should not get clear for reading ADG1MAXCOUNT register. However, may know the reason why you are reading ADG1MAXCOUNT periodically even though you didn't enbale enhanced mode?

    And also, how frequently you are reading it? If possible, share a demo code to test and confirm it on end, even if not possible also fine i will create one and will do testing.

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    The reason why we are reading ADG1MAXCOUNT periodically even though the application does not have Enhanced Channel Selection Mode enabled is as part of a periodic status check of module registers to ensure the configuration remains as expected.

    After having completed initialisation we enter the main loop which is executed every 20ms, in which a call is made to the function that reads and returns the latest data from the two ADC hardware instances (ADC1 and ADC2). This is shortly followed by a call to the function that performs the periodic status checking of a number of ADC module registers, including the ADG1MAXCOUNT register.

    Between the call to the read function and the status checking function, calls are made to a number of other functions which perform periodic status checking on other hardware modules.

    An estimate of the elapsed time between calling the read function and calling the status checking function would be less that 250us, we could measure this if you believe this information will be beneficial.

    The application is only using conversion group1 on both ADC hardware instances (ADC1 and ADC2).

     

    Kind regards,

    Paul.

  • Hi Jagadish,

    Have you managed to replicate this issue?

    Is there any other information that I can provide which may assist you?

    Kind regards,

    Paul.

  • Hi Jagadish,

    I have been asked to follow up on a response ... Have you managed to replicate this issue?

    Is there any other information that I can provide which may assist you?

    Kind regards,

    Paul.

  • Hi Paul,

    Apologies for the delayed response!

    I don't have exact same board so i tried with another Hercules board (TMS570LC4357):

    Here i am unable to reproduce the issue, as shown above after conversion i am continuously reading the MAXCOUNT register in while loop, but it is not clearing the G1_END bit.

    I do have another board which is TMS570LS3137, i will try with that one also. Mean time could you please verify my process and confirm it?

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    Apologies for the delay in responding but I have now received the following from my colleague who first reported and has been investigating this issue ...

    I have spent some time looking at this today and initially setup a test routine as close to the example provided by Jagadish below.

    I was able to replicate his results in the fact the G1_END bit is not affected / cleared by reading the ADG1MAXCOUNT register.

    I then created a new routine to check the MAXCOUNT registers for all ADC groups.

    I added a call to this new routine at the end of ADC_GetStatus

    If called on ADC1 then all reads of ADC1 fail (G1_END bit not set).

    If called on ADC2 then all reads of ADC2 fail (G1_END bit not set).

    So, the behaviour in our system is consistent, if we attempt to read the MAXCOUNT register for the ADC groups, this causes the conversion to fail (not complete).

    I then refined the routine to look at the groups individually and found it was the read of ADC_GROUP2 that consistently caused the conversion to fail.

    I then went back and modified the simple test harness to poll group 2 rather than group 1 and found that this does indeed either clear the G1_END flag of affect the conversion in some way such that is does not complete.

    I have been using modified versions of our ADC files rather than going back to the HALCOGEN source, so there are some differences from the tests Jagadish has conducted.

    This provides slightly different test results to that detailed in my notes from 2025-07-29 whereby we were seeing intermittent failures on when reading from ADC_GROUP1. As yet I haven’t been able to get MAXCOUNT ADC_GROUP1 reads to fail using the small test harness, but MAXCOUNT ADC_GROUP2 reads cause the fault consistently (every call) for ADC1 and ADC2.

    That said the ADC.c code has changed significantly since my original testing, particularly the sequence of the register reads, which may have some effect on this?

    Given the additional information above, please let me know whether you are now able to replicate the issue which we have been seeing.

    Kind regards,

    Paul.

  • Hi Paul,

    Apologies for the delayed response.

    Is it possible to setup one live debugging session? I want to verify this issue lively.

    I will be available from 9AM to 9PM IST.

    --
    Thanks & regards,
    Jagadish.