Hi,
I'm building an embedded system based on AT91SAM9260, receiving significant amount of data via USART working in sync mode at 6Mb/s.
The system works under control of Linux OS.
During tests I've stated that some transmitted bytes are lost. During discussion at comp.arch.embedded I was told, that the problem may be associated with congestion in the Bus Matrix, as at 6Mb/s the transfer of received character must be performed in 1.67µs.

I have moved the receiver buffer to the internal SRAM, but it didn't solve the problem.
Next suggestion was to reconfigure the Bus Matrix so, that access from PDC to SRAM has the highest priority.

I've read the AT91SAM9260 datasheet: http://www.atmel.com/dyn/resources/prod ... oc6221.pdf but the description of Bus Matrix is very scarce.
Looking at Fig 2-1 I can see, that there are 6 Masters (I and D in CPU, Ethernet, ISI, USB, PDC) and 5 Slaves (EBI, Periph Bridge, SRAM0, SRAM1, ROM), but I can't figure out what is their numbering?

Where can I find a better description of the Bus Matrix?
--
TIA & Regards,
Wojtek

hello,
some months ago i also tried to get some information about the bus matrix, but with no luck. atmel support told me that they don't have any more information except the datasheet. i also didn't find any examples dealing with this topic.

regarding your questions
you can find more information about the numbering of masters and slaves at chapter SAM9260 Bus Matrix.
you will also find there the reset values of the different configuration registers.

in your case PDC is master no. 2 and your sram ist slave no. 0 or 1.

what i would try is to change the Default Master Type of slave 0/1 to Fixed Default Master with master no. 2 as the default master. at this configuration a transfer from pdc to sram should have no latency.
i would also try to change slave 0/1 arbitration type to fixed priority arbitration and give master 2 a higher priority then all of the others.

from my point of view all of this changes are only effective if more then one master is accessing your slave 0/1.

hopefully this helps a little bit.

regards
gerhard

Hello,
I've checked the doc6221.pdf on another machine, and now I can see the following sections:
18.2.1 Matrix Masters (with numbers assigned to all masters)
18.2.2 Matrix Slaves (also with numbers)
and 18.2.3 Master to slave access.
This version of datasheet is labeled as 6221I–ATARM–17-Jul-09
Probably the version, which I had at home was older, or I was really tired ;-).

With the above information I can at least try to start to tune the matrix priorities...

EDIT:
Yes, I've checked the version of doc6221,pdf which I have at home. This is labeled as 6221H–ATARM–12-Aug-08 and it really doesn't contain numbering of bus matrix masters and slaves in sectionm 18, but it has this info in section 7.

EDIT2:
After analysis of the newest datasheet and of suggestions of gerhardf (many thanks!), I have came to the following conclusions:
I need to reconfigure the following registers:
MATRIX_SCFG0 and MATRIX_SCFG1 should be set to 0x010a0010 instead of default 0x00000010 (to switch on the fixed priority, with default master set to PDC)
MATRIX_PRAS0 and MATRIX_PRAS1 should be set to 0x00200300 instead of default 0x00000000 (toi assign the highest priority to PDC, lower to ETH and the lowest to other masters).
I will appreciate any suggestions and remarks.
--
Regards,
Wojtek

You have to watch the document changes. I tend to archive all the ones I download to keep a history/context, so when problems occur we can see what we were designing too.

[quote="wzab"]
EDIT2:
After analysis of the newest datasheet, I have came to the following conclusions:
I need to reconfigure the following registers:
MATRIX_SCFG0 and MATRIX_SCFG1 should be set to 0x010a0010 instead of default 0x00000010 (to switch on the fixed priority, with default master set to PDC)
MATRIX_PRAS0 and MATRIX_PRAS1 should be set to 0x00200300 instead of default 0x00000000 (toi assign the highest priority to PDC, lower to ETH and the lowest to other masters).
[/quote]
i didn't check the numbers but from the description it sounds good.

please tell us if this change fixes your problem.

regards
gerhard

by mistake I've posted a message before it was ready. How can I delete this message???

Thanks gerardf for suggestions. It seems, that now the situation is better, however I need to perform further tests.
--
Regards,
Wojtek

[quote="gerhardf"][quote="wzab"]
EDIT2:
After analysis of the newest datasheet, I have came to the following conclusions:
I need to reconfigure the following registers:
MATRIX_SCFG0 and MATRIX_SCFG1 should be set to 0x010a0010 instead of default 0x00000010 (to switch on the fixed priority, with default master set to PDC)
MATRIX_PRAS0 and MATRIX_PRAS1 should be set to 0x00200300 instead of default 0x00000000 (toi assign the highest priority to PDC, lower to ETH and the lowest to other masters).
[/quote]
i didn't check the numbers but from the description it sounds good.

please tell us if this change fixes your problem.

regards
gerhard[/quote]

As I just said in comp.arch.embedded.
There is an example (written by me) in at91bootstrap-2.13
ftp://ftp.at91.com/pub/buildroot (IIRC)
at91bootstrap is the proper place for such code.

/Ulf

I have put the code to the board initialization function.
It solved the problem of data lost between USART and PDC memory buffer, but
still some data are lost at high data rates (probably due to overhead introduced by the upper layer of the atmel_serial driver).

The final solution should probably use dedicated USART driver, moving data from the PDC bufer in SRAM directly to the memory mmapped by the client application...

BTW. The thread in comp.arch.embedded mentioned by Ulf is available at http://groups.google.com/group/comp.arc ... 0dbdb5e529

The patches to the atmel_serial.c, which I have introduced are available at: http://groups.google.com/group/alt.sour ... b8b0c0ac4b

Thanks gerhardf and Ulf for your help!
--
BR Wojtek