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.

LAUNCHXL-TMS57004: Using HalCoGen gen code with FreeRTOS , HET pwm not starting ...

Expert 1965 points
Part Number: LAUNCHXL-TMS57004
Other Parts Discussed in Thread: HALCOGEN

I spent time trying to figure out why,  unless I set the task's Privilege bit, my HET's  PWM will not work. Using all 'stock' code as generated by HalCoGen for LS043xx with FreeRTOS, and just putting 'driver' / hal init into a task. 

The odd things are : I can do init calls like - adcInit(), hetInit() - without settings the tasks MPU privilege bit , and , these peripherals do appear to be initialized. By initialized I mean : ADC sampling works , e.g. with RTI 0 trigger, and I get ADC interrupts on correct time & values match input voltages.  Het gets initilized, it _seems_, at least say HET output pin(s) get to default output set at init (e.g. set DOUT 1) as I see externally.

BUT,  when it comes to PWM from HET, then this does NOT start, unless hetInit() was called from privileged task OR from main before scheduler starts.  So whether you enabled PWM to start by default in HalCoGen in HET init, or if you call pwmStart() .. later,  this does not work, PWM won't start.  Also, trying to trigger same ADC which works with RTI trigger but from HET pinX won't trigger either.  In other words, my ADC with group triggering from RTI works, but group for e.g. triggering from HET1_8 doesnt as nothing coming in from that HET.

Also odd, is that it all 'silently' fails, there is no reason or crash or abort anywhere, as I would _think_ I should get if MPU is working and I'm trying to init a privileged section. But nothing of the sort.

So I conceptually don't understand it : why is this like this,  hetInit() silently will prevent PWM from working later, _unless_ it was invoked from a privileged task.  (i.e, the privilege bit on priority). 

I would expect MPU (if configured accordingly..) to trigger abort as soon as I touch HET registers if  un-privileged when initializing, or when trying to start pwm as that accesses HET RAM registers. But nothing of the sort, all silently seems calle d& returned, yet PWM will not work ..

Any light on this ?  Do all HalCoGen's auto gen drivers/hal sort of silent when invoked from un-privileged task? And why (reason) I have such HET isssue .. 

  • Most peripherals have registers that can only be written to if the CPU is in a privileged mode. These are clearly identified in the reference manual. The specific bit field is designated as "R/WP" type, which means that that bit-field can be read in any CPU mode, and can only be written to in a privileged CPU mode (any mode but user mode). This check is done inside the peripheral itself, and the defined response is to ignore the write access if it is executed with the CPU in user mode.

    You can configure the PCR registers to enable privileged-mode access restrictions for all registers in a certain (or all) peripheral per the peripheral select. In this case there will be an error response from the PCR itself if a write is attempted to the select peripheral(s) in user mode.

    Hope this helps.

  • Hi 

    Partially yes.  But as I wrote above, is seems to not work - i.e., peripheral W access is NOT ignored - for some of HalCoGen drivers, such as ADC in my example, yet and only __partially__ (as I explained in OP) ignored for HET (i.e, het is partially initialized as I see).

    My guess, HalCoGen autogen code may be not consistent in how it partitioned protected memory perhaps, or  i need to see what's configured how by default in HalCoGen.

    Thank you for response.

    EDIT: Not sure further, because for example,  I can init Het in the privileged task, and then start pwm -which does W access  - from un-privileged task. This shouldn't work, as I understand ..?  Unless NHET1 memory (in my case)  is not considered for  privileged access ...

  • Not all control registers have this restriction to only be writable in privileged mode. For example, in the ADC peripheral, the only registers that have this restriction are the ADC Reset Control register and the ADC Parity Control register. The ADC module is out of reset by default, so if you don't enable parity checking for the ADC RAM then configuring the ADC does not require the CPU to be in a privileged mode.

    Similarly you can check for the HET which registers require privileged mode write access.