• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 99 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.

TMS320F28P650DK: Configuring external reference in CMPSS

Gildas ROLLAND
Intellectual 650 points

Part Number: TMS320F28P650DK
Other Parts Discussed in Thread: SYSCONFIG, C2000WARE

Hi,

I'm using test project on F28P65 launchpad with an analog signal connected to ADCINA8 and want to use it in CMPSS, so CMPSS8. In sysconfig I select external pin as negative input source and input signal 1 as CMPHNMXSEL to have L5:A10/GPIO213 used as reference input.

Compilation is OK but execution falls into __error__ due to ASysCtl_selectCMPHNMuxValue execution. Code generated by sysconfig send select parameter ASYSCTL_CMPHNMUX_SELECT_8 (with value 0x80U) but function start by ASSERT(select <= 0x7FU);

It's look like HNMUX could be configured only for CMPSS 1 to 7 even if F28P65 has 11 CMPSS and CMPHNMXSEL register contains 11 configuration fields.

CCS 12.8.1, SysConfig 1.28.0, C2000Ware 26.1.0.00, compiler 25.11.1.LTS

(for information same assert is present in F28P55 driver even if it has only 4 CMPSS, so all CMPSS drivers should be fixed to have assert containing the right value for each processor)

Regards

  • +1
    TI__Mastermind 39373 points

    Hi Gildas,

    Thanks for the details and for confirming the platform. Yes — this is a known driverlib limitation, not a hardware restriction. A few points to close the loop:
    1. Confirmation of the bug: The ASSERT(select <= 0x7FU) in asysctl.c (used by ASysCtl_selectCMPHNMuxValue) was written when only CMPSS1–CMPSS7 existed on earlier C2000 devices, and hasn't been updated for the F28P65x (11 CMPSS instances) or F28P55x (though it only has 4, so it's a harmless but sloppy leftover there). The CMPHNMXSEL register in the TRM does support the additional select fields for CMPSS8–CMPSS11, so the hardware and register map are fine — only the driverlib validation is stale.
    2. Workaround validity: Bypassing the assert (or writing directly to the CMPHNMXSEL register field via low-level register access instead of going through ASysCtl_selectCMPHNMuxValue) is a safe workaround. Several similar cases on F28P65x (e.g., missing SELREF/COMPDACCTL definitions) turned out to be documentation/header gaps rather than functional hardware issues, so once you bypass the assert, the mux itself should behave correctly per the TRM description.

    I'll file this against the C2000Ware driverlib for asysctl.c (ASysCtl_selectCMPHNMuxValue) to fix the assert bound based on device-specific CMPSS instance count (using DEVICE_CMPSS_COUNT or similar per-device macro), and will flag the F28P55x driver for the same audit as you suggested, so all device variants get a bound check matching their actual CMPSS instance count rather than a hardcoded 0x7F. In the meantime, the register-bypass approach should safely unblock your development.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Intellectual 650 points

    Hi,

    I have already manualy written into CMPHNMXSEL register and comparator is working as expected.

    Regarding the bypass of the assert, as I use sysconfig the call to ASysCtl_selectCMPHNMuxValue  is not in my source code but in code generated by sysconfig, so the only way to avoid this call is to not configure input1 as negative comparator input which is not really clean. I also could not comment the assert as I link the driver.lib file contains in c2000ware.

    Thanks