TM4C129 HB16 address bus is stuck at 0x00

Amit,

Its working now :-)

I was under the assumption that the address will AUTOMATICALLY increment with every write.

thanks..

Hi Amit,

This reporter was under the same assumption as poster Khaled.  (i.e. automatic increment/decrement of address w/each transaction {read or write})  That feature is often desirable (i.e. transacting w/memory or display controllers) - yet accommodates those occasions when an address "jump" is indicated/required - as well.  And (pardon) this auto increment/decrement of external address is (predictably) found on multiple, other ARM MCUs.

Manually entering the address for each/every transaction seems wasteful (slowing & inefficient) - might there be some means to automate the address increment on MCUs here - just as poster Khaled seeks?

Thanks your time/attention...

cb1- said:

Manually entering the address for each/every transaction seems wasteful (slowing & inefficient) - might there be some means to automate the address increment on MCUs here - just as poster Khaled seeks?

Is that not (part of) the purpose of DMA?

Robert

Robert Adsett said:

Is that not (part of) the purpose of DMA?

May be - as my writing stated - auto address increment/decrement is not, "held hostage" to DMA on other Cortex M-4s... 

Note that my post was an obvious follow-on to poster's - and sought further (perhaps insider) detail...

Hello cb1,

In the original code the address pointer is not constant. So when data is accessed the address remains constant. Also since the address pointer is overloaded as uint16_t, the address though will perform a 16-bit transfer, but due to lack of change on the address itself the same address will present itself.

Regards

Amit

I think that the question that we should be asking our selfs: can we change the code such that the address will update/increment with every read/write.

Khaled.

The C idiom for that is

    for(i = 0; i < 10; i++) {
        word  = (uint32_t) *g_pusEPIFPGA++;        //    read lower 16bits
        word |= ((uint32_t) *g_pusEPIFPGA++) << 16;    //    read upper 16bits

        u32DataIn[i] = word;
    }

But that should not affect the code generation.  It does affect readability.

I don't remember if the Cortex has auto-incrementing address mode but changing the code should not affect its use.

The other unasked question is, does it matter?

Robert

cb1- said:

auto address increment/decrement

Khaled - believe that's exactly what was asked (above.)

Amit - may "automatic" inc/dec of the external bus be achieved via some MCU register setting - and w/out requiring uDMA (adds unwanted complexity & limits uDMA availability for other tasks) or manual update of the external address?

It appears the AHB bus may have provision or autoincrementing

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337i/BABGBEEC.html

Whether this peripheral is on the AHB bus and that register is available to program is open to question.

Also depending on depending on access restrictions (and the particular library implementation) do not forget memcpy.

Although the "is this worth it?" question still rises. You should probably measure the performance to see if it is adequate before optimising it further.

Robert

Hello cb1,

The Non-Block Read FIFO can be used to do the same. It consist of 3 register. EPIRSIZEn to indicate the width of the transfer, EPIRDADDRn for start address of the transaction and EPIRPSTDn which is to set the number of transfers.

The user then has to set the threshold in the EPIFIFOLVL register so that an interrupt can be triggered when the required level is reached and CPU can use LDMIA instruction to do a burst transfer.

Regards

Amit

How about the write? If we transfer data to the write fifo (either direct write or using uDMA), will the address automatically increment as well?

Khaled.

Hello Khaled,

All write transactions go through the Write FIFO. I don't believe that is an optional path

Regards

Amit

But my question was: will the write address increment as well? and how we set it up.

Khaled.

Hello Khaled,

The Write FIFO stores the address and the data. Hence the way it is accessed on the AHB Bus Interface decides how the address will be presented on the interface.

Regards

Amit

Thanks Amit,

I didn't understand your answer its a little bit vague. Do you have an example/documentation?

Just to let you know, I alread have the answer for the question that I have asked originally.
But after all those messages that has been exchanged, It became a curiosity. I want to understand how it works and change my code if I find a solution that is better than the one that I'm currently considering.

thanks.

Khaled.

Hello Khaled,

I don't think it is documented or has an example code with it. The only documentation would exist in the data sheet chapter for EPI. To explain it better: The Write FIFO is a 4x32 bit FIFO which holds the write transaction being done from the CPU/DMA. Since it is possible that the Line Side may run slower than the system clock, to avoid stalling the bus, the FIFO holds the Address and Data. This way the CPU/DMA can do a burst write (CPU case is STMIA instruction) and then go to perform another operation with another peripheral. The EPI will schedule the transaction onto the Line Side. The manner in which the address is presented on the bus depends on the manner it has been written into the FIFO. So if the 4 units of data are written with incrementing address, the address on the line side would increment as well. If the data has been written with a constant address, the data will be sent out to a constant address.

By Line Side I mean the Pins coming out of the device. I hope this clarifies the operation of WFIFO

Regards

Amit

How about non uDMA write?

for the read in epi.c several function are available to configure the read fifo, read address, and read the data ( EPINonBlockingReadConfigure, EPINonBlockingReadStart, EPINonBlockingReadGet32..)

I can't find similar function for the write!

Khaled.

Hello Khaled

There are only two system initiators for EPI. CPU and uDMA. Irrespective of source of the write data the WFIFO works in the same manner as described before. That is the reason why there are no such functions.

Regards

Amit

Amit Ashara said:

Irrespective of source of the write data the WFIFO works in the same manner as described before. That is the reason why there are no such functions.

Pardon - but the absence of those (reasonably) expected write functions - noted by Khaled - seems very much a vendor, "shortcut" - and one destined to derail & confound your user multitudes.

Are the presence, highlighting and proper management of those two, "system initiators" adequately detailed w/in the MCU manual?  Seems unwise & inefficient to hold,"optimal usage methods" hostage to privileged, insider information...

cb-1

I agree with you. for uDMA write I believe that the address is set using the uDMAChannelTransferSet( ) function.

But how about CPU write! how do we set the write address?

Khaled.

Hello Khaled, cb1,

The Write FIFO is in an internal buffer management which is not exposed to user programming unlike the NBRFIFO which is also an internal buffer management with user programming.

The Bus Masters to the EPI is mentioned in section on "Master Access to EPI" of the EPI Chapter in the Data Manual.

As noted by Khaled, uDMA write is set by the uDMAChannelTransferSet(), while the CPU write is set by the use of address for external Bus operation in the same manner as any peripheral write operation using the address of the peripheral. For example if 0xC000.0000 is the address mapped to the Bus in EPI register, the CPU access will be done by HWREG or in the specific example the pointer set in the code for accessing the bus

Regards

Amit

Hi Amit,

That explanation is quite good - subject is somewhat complex and (perhaps) both uDMA and EPI sections - w/in MCU manuals - would benefit from the further detail & clarity you've added, here.

Thank you, Amit - as always - your efforts are appreciated.

(and - as noted in the recent," ARM Peripheral comparison" post - ARM vendors implement their DMA & external bus access often by different means - adding to the challenge of simple competence - let alone full understanding or mastery by users...)

Amit,

Apparently I'm not as good as cb1.

When you sait : "For example if 0xC000.0000 is the address mapped to the Bus in EPI register, the CPU access will be done by HWREG..."

Do I understand from your comment that the only way to perform an EPI write is by setting a memory mapped location using the EPIAddressMapSet( ) function and then write to that memory?

In all cases, how do we set the address to a specific value? I'm not able to find EPI write example code that does not used memory mapped approach. Do you have an example code?

thanks.
Khaled.

Hello Khaled,

Your interpretation of a write to the memory is correct. Based on what is set in the EPIAddressMapSet the memory mapped location is accessed.

You can perhaps go through the example

C:\ti\TivaWare_C_Series-2.1.0.12573\examples\peripherals\epi\sdram.c

to be able to see how write is being done.

Regards

Amit