My goal is: Getting the Device Dashboard Demo running out of the box, on the ATSAME54-XPRO board.
My actions were: Compiling the source using the X32 compiler from MPLab X IDE.
My expectation was: A working demo.
The result I saw: All pages on the dashboard seemed to work except the last page (Events). On this particular page the ajax request from the client would remain unanswered.
My question is: Consider adding the following register settings to same54.c
line 111: GMAC_REGS->GMAC_DCFGR = GMAC_DCFGR_DRBS(0x18)|GMAC_DCFGR_RXBMS(GMAC_DCFGR_RXBMS_FULL_Val)|GMAC_DCFGR_TXPBMS(1);
Additional information:
While debugging with Wireshark I found that the actual packet containing the request for /api/events/get, would never even get a TCP ACK back from the board, let alone a full reply. This leads to retransmissions from the client, which in turn also did not get any reply. A fresh call to another URL (eg /api/stats/get) then continued to work as expected. Digging deeper, it appeared that as soon as the size of the ethernet frame went over 488 bytes, the packet would not be received by the GMAC, and never put in the receive buffers.
The datasheet of the ATSAME54 states on page 488 that there is a Receiver Packet Buffer Memory Size Select, which by default is set to 4KB/8 Kbyte, so 512 bytes. If I set this to 0x03 (FULL size) then the problem disappears completely.
I think that this issue does not always show itself because it depends on the browser being used (I'm using firefox 119.0.1 on windows) and what specific headers it inserts into the request by default. This determines whether the resulting packet on the wire is just below or just over the observed 488 byte boundary.
Also, I may have spotted something in the get_clock_rate method. The list of possible clock dividers is now:
uint8_t dividers[] = {8, 16, 32, 48, 64, 128}; // Respective CLK dividers
However the datasheet lists 8, 16, 32, 48, 64, 96 as possibilities on page 483.
cpq
commented
7 months ago
Additional information: While debugging with Wireshark I found that the actual packet containing the request for /api/events/get, would never even get a TCP ACK back from the board, let alone a full reply. This leads to retransmissions from the client, which in turn also did not get any reply. A fresh call to another URL (eg /api/stats/get) then continued to work as expected. Digging deeper, it appeared that as soon as the size of the ethernet frame went over 488 bytes, the packet would not be received by the GMAC, and never put in the receive buffers. The datasheet of the ATSAME54 states on page 488 that there is a Receiver Packet Buffer Memory Size Select, which by default is set to 4KB/8 Kbyte, so 512 bytes. If I set this to 0x03 (FULL size) then the problem disappears completely. I think that this issue does not always show itself because it depends on the browser being used (I'm using firefox 119.0.1 on windows) and what specific headers it inserts into the request by default. This determines whether the resulting packet on the wire is just below or just over the observed 488 byte boundary.
Also, I may have spotted something in the get_clock_rate method. The list of possible clock dividers is now: uint8_t dividers[] = {8, 16, 32, 48, 64, 128}; // Respective CLK dividers However the datasheet lists 8, 16, 32, 48, 64, 96 as possibilities on page 483.
ATSAME54-XPRO board, compiled with XC32.