TMS570LC4357: disconnect DMA channel from HW trigger lines

Hi all,

just a remark to Jiri's post-scriptum: yes, description of bitfield within the register DREQASI0[0..7] is a bit confusing - there are 6 bits available to select an appropriate HW request for each DMA channel as e.g. illustrated in Figure 20-4. DMA Request Mapping and Control Packet Organization of TRM SPNU563–May 2014.

Cheers, Jiri

No reaction? We want to now if proposed solution to set DREQASI0 out of range is valid.

Jiri,

First, I apologize for the delay in getting to your questions.

Second, I don't see any reason why you shouldn't be able to set it to 0x3F as noted in the post you linked to. To be certain this doesn't cause a problem, please be certain your testing specifically addresses this initialization and confirms no side effects in the triggering of the DMA.

Dear Chuck,

you are right - almost everything can be proven by performing a set of test cases on the customer side. On the other side, a customer has purchased the device that was certified so, I would expect, a huge amount of test activities had been performed by TI and approved by the notified body during the certification process.
Another perspective is about the test coverage - a customer is in a complicated situation to evaluate which test coverage is sufficient :-)
I mean that TI has knowledge of internal structure and mechanisms (VHDL source code) of the DMA controller - so I would say there could be an easy static analysis of VHDL code performed on the TI side to prove that values "above" the allowed (by the inaccurate TRM) thresholds do NOT affect proper and expected behavior.
And the last (not least) statement - the TMS570LC4357 device has got the certification up to SIL3 - as consequesnces I would expect an official work-around / errata item by TI to any undocumented and/or undefined / dangerous behavior.

Thanks a lot,
Best regards, Jiri

Jiri,

Your points are well noted and understood. Also consider that during development and assessment there are quite a few resources allocated to the development process and many pieces of that information sometimes not passed on to everyone involved. For sure it is a safety device certified up to ASILD and SIL3. Of particular interest in these certifications is to provide evidence that the devices were developed in a certified process that is designed to minimize the risk of systematic faults. Also of particular interest according to the standards is to document the appropriate qualitative and quantitative information to demonstrate the detection and/or avoidance of random faults. These two points combined lead to the necessary reduction of risk due to random and systematic faults in the device.

Note that my comments to you on this particular task were presented with a certain degree of confidence that the behavior of writing the higher value to the field would be benign. i.e., the module design is capable of up to 64 channels which was expanded from 32 in prior devices. As is often the case with our IP, the unimplemented signals are often tied off or handled in a way as to not impact the device operation and I strongly suspect the same in this case. Thus I don't have a great deal of concern that this is in any way, shape, or form a fault that would/should be considered as part of the overall certification (note that this type of fault would fall into the systematic fault area.) I also would not consider it to rise to the level of a HW bug resulting in the need of an errata advisory.

As with any Functional Safety implementation there is a clear distinction between what is the responsibility at the device level vs. what is the responsibility at the integrator level. In this case, you are asking to use the device in a way that is not defined in the collateral so it is not necessarily a defined requirement as to the specific behavior which is why a stated that if you would like to use an undocumented feature of the device, it is requested that you do so in a cautious way with ample diligence given to the testing of that undocumented feature that is outside the scope of the expected use scenario.

In regard to design resources, yes, if I had access to the RTL/design database, I could theoretically have a look at these signals and potentially see how they are hooked up. In the end, I don't have this access so this is not an option at this point.

Also, please note that if you do find an inaccuracy in the TRM, please use the document feedback mechanism to provide feedback. We are in the process of evaluating updates to our TRMs and any inaccuracy or clarification would be a valid candidate to include in these updates.