MSP432P401R: msp432 dma impact on cpu cycles

Eric Decker said:

I've been through the data sheet and the TRM for the msp432p401r and can't find anything that talks about the DMA controllers impact on main cpu access to shared resources.

No wonder you can't find anything that talks about the DMA controllers - because you are reading wrong document. Datasheets show specification, not functionality. You shall be reading Technical Reference Manual, SLAU356

Ilmars said:

Eric Decker

I've been through the data sheet and the TRM for the msp432p401r and can't find anything that talks about the DMA controllers impact on main cpu access to shared resources.

No wonder you can't find anything that talks about the DMA controllers - because you are reading wrong document. Datasheets show specification, not functionality. You shall be reading Technical Reference Manual, SLAU356

Seriously?  First I clearly state that I've been looking in both the datasheet as well as the TRM.

Was this worth your time to be unhelpful?

And datasheets with specifications do talk about interactions between different masters on the memory system.  It is not unreasonable to look in both places.

In fact most of the information I've included in my next post comes from the datasheet not the TRM.  So go figure.

here is what I've gleaned so far...   Much is conjecture.  Basically, I'm asking what are the different regions of the memory system and what happens when there is a collision between multiple masters.  More information about the behaviour of the memory system would be very helpful.

Is the memory multi-ported?

from the datasheet I see access priority

If the processor is accessing a peripheral, does it use SBUS or DCODE?

If the DMA is accessing SRAM doing a block to block copy and the processor is fetching instructions instructions, do they not interfere at all?

If the processor is executing instructions out of SRAM say in the 0100xxxx area (ICODE?)  and the DMA fires up doing a block copy in SRAM 2000xxxx will the DMA lock the processor out completely?

what are the major bus masters?   When do they interact?

The datasheet talks about 4 bus masters: ICODE, DCODE, SBUS, and DMA

My understanding is  ICODE is used when doing instruction fetchs, DCODE used by the cpu for literal etc, code space, SBUS used for peripheral access?  Is there a definitive guide that talks specifically about how the bus masters work and when they are utilized.

When is the SBUS used?

thanks

Such information use to be scattered in datasheets/reference manuals ...

Eric Decker said:

Was this worth your time to be unhelpful?

At least I tried :) Yes, I missed (uncommon here) "TRM"  abbreviation. Sincere apologies for being unhelpful.

Besides peripherals more or less everything else in msp432 is made by ARM, so looking into ARM documentation could help actually.

Eric Decker said:

In fact most of the information I've included in my next post comes from the datasheet not the TRM.  So go figure.

Yes, you are right. Msp432 datasheet coverage and structure differ from msp430 documents. For instance you would never see chapter like "6.6.1 Master and Slave Access Priority Settings" in the datasheet of msp430.

IMHO key piece of information that most likely answers your original question is (SLAU356E, page 446):

which essentially say that DMA cannot hold bus for more than single cycle and arbitration of concurrent CPU & DMA access to single bus will look like round-robin. At least this is how I get it.

p.s. It was TRM, not datasheet ;)

thanks mon, no worries.

Yeah the docs are a mismash of ARM style and TI style which is interesting.  Not the clearest.

I get that once on the bus it does a single transaction, one of the questions I have is  how many different operations can be done in parallel, and who gets the bus when.

that isn't clear from what I've seen so far.

In particular, if the CPU is doing inst fetchs from Flash (ICODE) and the DMA is wacking on RAM, is there any interference?  Or do both run at full speed.  My guess is yes, but a guess.

Now lets say the CPU is running instructions out of RAM in the 0x0100FFFF region and the DMA is wacking on RAM,  The cpu is using ICODE at priority 4 and the DMA using DMA at priority 1, I would think the CPU would get starved.  Clarification would be good.

thanks for the effort.

appreciated.

Eric Decker said:

In particular, if the CPU is doing inst fetchs from Flash (ICODE) and the DMA is wacking on RAM, is there any interference?

No. You can see this by looking into "access priority" table 6-31. ICODE, DCODE, SBUS and DMA are busmasters which have access to common bus slaves: memories and peripherals. Masters all can work in parallel as long as they do not collide requesting access to same slave.

Eric Decker said:

Now lets say the CPU is running instructions out of RAM in the 0x0100FFFF region and the DMA is wacking on RAM,  The cpu is using ICODE at priority 4 and the DMA using DMA at priority 1, I would think the CPU would get starved.

Yes. CPU will get RAM-starved for single bus cycle - if both, CPU and DMA tries to access RAM at the same time (same bus cycle). However according to my previous post, DMA is destined to let CPU access RAM in the next bus cycle and only after that it can do next transfer.

[edit]

Eric Decker said:

Yeah the docs are a mismash of ARM style and TI style which is interesting.  Not the clearest.

That's because TI just copy/paste contents of ARM docs - like most of ARM uC manufacturers do.

Just something that nagged me the last day.
TI's MCU documentation strategy seem quite inconsistent here. The MSP432, as a Cortex M4 device, has separate datasheet and TRM. And the TM4C, TI's other Cortex M4 device, has an All-In-One "Datasheet".

Ilmars said:

No. You can see this by looking into "access priority" table 6-31. ICODE, DCODE, SBUS and DMA are busmasters which have access to common bus slaves: memories and peripherals. Masters all can work in parallel as long as they do not collide requesting access to same slave.

It isn't clear to me from the docs what exactly are the seperate slaves.   What are seperatly addressable entities?  Where are the bottlenecks during access?

Ilmars said:

Yes. CPU will get RAM-starved for single bus cycle - if both, CPU and DMA tries to access RAM at the same time (same bus cycle). However according to my previous post, DMA is destined to let CPU access RAM in the next bus cycle and only after that it can do next transfer.

I don't get this from the documentation.  I would think that if the DMA were doing a block of RAM, then on the next cycle it would again be requesting the slave, it has higher priority than the CPU, and it would continue to starve the CPU (it being the DMA).

What you are suggesting would be round robin (which makes sense to me) but I don't see evidence of this in the docs.

So what are your assertions based on?  Did you do an experiment?

thanks

eric

Eric Decker said:

So what are your assertions based on?  Did you do an experiment?

Knowledge of CPU systems architecture and also knowledge of ARM uC of another manufacturer. No, I did not experiment. Thou you can do it :) Just make RAM->GPIO DMA multiword transfer of alternating 00 FF words, run GPIO-toggling CPU code from RAM at the same time, see how they both work together colliding on RAM and GPIO slaves, with scope.

Anyway if TI documents does not answer questions about ARM core/bus/controller internals, you are advised to read ARM documentation. Better just read info where it is rather than wait for someone to bring it to you.

Ilmars said:

Anyway if TI documents does not answer questions about ARM core/bus/controller internals, you are advised to read ARM documentation. Better just read info where it is rather than wait for someone to bring it to you.

AFAIK, many details of the bus matrix implementation are actually left to the silicon vendor, i.e. are not determined by ARM. This would place responsibility back at TI's side.

As an example of how it could be done, look here (competitor, see e.g. pages 48/49).

And I still think TI could harmonize their documentation structure. Spatial distribution is no excuse.

f. m. said:

AFAIK, many details of the bus matrix implementation are actually left to the silicon vendor, i.e. are not determined by ARM. This would place responsibility back at TI's side.

As an example of how it could be done, look here (competitor, see e.g. pages 48/49).

that link doesn't work

Eric Decker said:

that link doesn't work

Sorry, another try:

http://www.st.com/resource/en/reference_manual/dm00043574.pdf

It is the STM32F3 reference manual,  named "DM00043574.pdf", document designated as RM0316.

I'm looking for something similar but for the TI MSP432 implementation.

The way the buses and interconnect is laid out is vendor specific.

TI? Could I get some more information about the bus matrix in the msp432?

f. m. said:

It is the STM32F3 reference manual,  named "DM00043574.pdf", document designated as RM0316.

Well, I do not see anything that would say that ST implemented other than AHB bus matrix. Not even sure which version. In contrast TI clearly told us that. What I see in ST doc is just bus matrix configuration information which is essentially "Table 6-37. Master and Slave Access Priority" in case of msp432. After all multi-master bus matrix is just multi-layer mux. Nothing much to implement differently than it is already done by ARM.

f. m. said:

And I still think TI could harmonize their documentation structure. Spatial distribution is no excuse.

Agreed :) TI shall clearly tell how bus and it's arbitration works in msp432. - Telling that bus used is AHB-Lite with only SINGLE transfer support is kinda obfuscated way to tell how it works.

p.s. I am afraid that TI is not that focused on msp432, documentation is one of the proofs. Soon it will be 2 years since release of the msp432, but how many different chip variants are released since then?

Ilmars said:

Well, I do not see anything that would say that ...

My point was mainly about documentation, not about implementation. Details about burst/word transfers and arbitration are further clarified in the DMA section.

Ilmars said:

p.s. I am afraid that TI is not that focused on msp432,

A more logical core decision would have been the M0+, or the new M23. Also notice that any M0/M0+ variant is absent in the TMxC portfolio, very likely with the intention not to cannibalize the MSP430 sales.

It seem worth remembering that base for the current TM4C was acquired with Luminary Micro (LM3), and did not originate within TI.

And as a side note, the MSP432 bears very few resemblance with the TM4C, judged by the peripherals.

f. m. said:

My point was mainly about documentation, not about implementation.

Then why did you say implementation instead of documentation? ;)

f. m. said:

AFAIK, many details of the bus matrix implementation are actually left to the silicon vendor

p.s. Engineering is exact "science".

f. m. said:

A more logical core decision would have been the M0+, or the new M23.

I don't want to investigate reasons, but SiLabs EFM32 Gecko uC's and stm32L1-series (low power) also are Cortex-M3. That could be something

Ilmars said:

Then why did you say implementation instead of documentation? ;)

Implementation of the actual silicon by the vendor, which implies the obligation for documentation.

Ilmars said:

p.s. Engineering is exact "science".

At the moment, I don't have the time and the nerve to delve that deep into bus matrix / DMA detail of TI and STM32 chips. Rather one from a Japanese vendor.

P.S. You should check out the documentation for equivalent japanese products (like Renesas RX600 or Fujitsu/Spansion/Cypress MB9Bxx). Even their FAEs admit it's almost uncomprehensible.

f. m. said:

P.S. You should check out the documentation for equivalent japanese products (like Renesas RX600 or Fujitsu/Spansion/Cypress MB9Bxx).

No, thanx. Everybody have it's weakness, not necessarily documentation :) I am fine with what I know already

Sounds like you know those already ... ;-)

Anyway, time to turn to family business now. A Merry Christmas and a Happy New Year to everybody !