Jan 30, 2020
07:52 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 30, 2020
07:52 AM
Hello All,
I am using Triboard TC27 working on QSPI non-DMA method. When I tried to transfer the the data from the TxBuffer Master(0x01,0x02,0x03,0x04) and the slave receive Buffer receiving data as (0xff, 0xff, 0xff,0xff).
I used Master and slave communication from the Triboard itself(QSPI 0 Master and QSPI 2 Slave).
When I tried the same program another triboard TC277(my colleague's) the same program works fine.
Kindly help me whether the issue is in board or the program? If the issue is board how to reset it back to normal.
Thank you everyone in advance,
Deepak
I am using Triboard TC27 working on QSPI non-DMA method. When I tried to transfer the the data from the TxBuffer Master(0x01,0x02,0x03,0x04) and the slave receive Buffer receiving data as (0xff, 0xff, 0xff,0xff).
I used Master and slave communication from the Triboard itself(QSPI 0 Master and QSPI 2 Slave).
When I tried the same program another triboard TC277(my colleague's) the same program works fine.
Kindly help me whether the issue is in board or the program? If the issue is board how to reset it back to normal.
Thank you everyone in advance,
Deepak
- Tags:
- IFX
6 Replies
Mar 31, 2020
02:45 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 31, 2020
02:45 AM
Dear deepakseshan1 and all,
I am also using TC277 Triboard and the QspiCpuDemo of iLLD demo code, but QSPI2 Slave can not work properly.
I also used the Logical Analyzer to check the transmission, I could count the SCLK and MTSR, The QSPI0 Master transmits data correctly, but the MRST only show the 0x00 and 0xff periodically as the attached picture shows.
I don't have another TC277 Triboard to verify.
Does anyone have experience about this kind of issue?
Please kindly advise.
I am also using TC277 Triboard and the QspiCpuDemo of iLLD demo code, but QSPI2 Slave can not work properly.
I also used the Logical Analyzer to check the transmission, I could count the SCLK and MTSR, The QSPI0 Master transmits data correctly, but the MRST only show the 0x00 and 0xff periodically as the attached picture shows.
I don't have another TC277 Triboard to verify.
Does anyone have experience about this kind of issue?
Please kindly advise.
Apr 02, 2020
01:12 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 02, 2020
01:12 AM
Hi
did u connect the QPSI0 & QSPI2 port pins together on the TC277 triboard extension board? (ie port pin P20.14 to P15.5, P20.12 to P15.7)
when using the debugger, did the interrupts come in? (ie, ISR_qspi0_Tx, ISR_qspi0_Rx)
please check.
did u connect the QPSI0 & QSPI2 port pins together on the TC277 triboard extension board? (ie port pin P20.14 to P15.5, P20.12 to P15.7)
when using the debugger, did the interrupts come in? (ie, ISR_qspi0_Tx, ISR_qspi0_Rx)
please check.
Apr 07, 2020
12:10 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 07, 2020
12:10 AM
Hi VincentWan,
Thanks for your reply.
I connected the QSPI0 & QSPI2 port together via the extension board on the TC277 triboard as the picture show, and I removed the R302 and the EEPROM from the TC277 triboard too.
When I use the debugger, the interrupts come in as the pictures showed.
The SFR View 1 showed the [Slave Transmit and Receive] in QSPI2_GLOBALCON after ISR_qspi2_Rx interrupt happed.
But the spi0RxBuffer is still received 0xff (255), (no 0x00 (0) after I removed the EEPROM), and spi2RxBuff is still received 0x00 (0).
Do you have any idea for this issue?
Thanks for your reply.
I connected the QSPI0 & QSPI2 port together via the extension board on the TC277 triboard as the picture show, and I removed the R302 and the EEPROM from the TC277 triboard too.
When I use the debugger, the interrupts come in as the pictures showed.
The SFR View 1 showed the [Slave Transmit and Receive] in QSPI2_GLOBALCON after ISR_qspi2_Rx interrupt happed.
But the spi0RxBuffer is still received 0xff (255), (no 0x00 (0) after I removed the EEPROM), and spi2RxBuff is still received 0x00 (0).
Do you have any idea for this issue?
Apr 07, 2020
11:40 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 07, 2020
11:40 PM
Hello deepakseshan1,
did you try using the example SPI_CPU_1? It has been reworked on the last release, together with its tutorial: SPI_CPU_1 tutorial
It has been developed for the KIT_AURIX_TC297_TFT board but it can be easily ported to any other kit.
hope it helps,
teoBits
did you try using the example SPI_CPU_1? It has been reworked on the last release, together with its tutorial: SPI_CPU_1 tutorial
It has been developed for the KIT_AURIX_TC297_TFT board but it can be easily ported to any other kit.
hope it helps,
teoBits
Apr 08, 2020
08:15 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 08, 2020
08:15 PM
Hi teoBits,
Very thanks for your reply.
The example code could run on the TC277 Triboard properly.
This information is really helpful.
Thank you again,
Wayne Chen
Very thanks for your reply.
The example code could run on the TC277 Triboard properly.
This information is really helpful.
Thank you again,
Wayne Chen
Jan 21, 2024
10:36 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 21, 2024
10:36 AM
-
QSPI FIFO Buffer Issues: The TriBoard TC277 is encountering problems with the QSPI FIFO buffer, which may be impeding the normal operation of the device.
-
Potential Causes:
- Insufficient configuration: Verify that the QSPI FIFO buffer is correctly configured to meet the requirements of the application.
- Hardware malfunctions: Check for any physical issues or malfunctions in the QSPI hardware that could be affecting the FIFO buffer.
-
Debugging Steps:
- Use debugging tools: Employ debugging tools, such as a JTAG debugger, to inspect the QSPI FIFO buffer's behavior during runtime.
- Log and analyze data: Implement logging mechanisms to capture data related to QSPI transactions, allowing for in-depth analysis.
-
Merlin AI Integration:
- Leverage Merlin AI for anomaly detection: Integrate merlin ai capabilities to monitor the QSPI transactions and automatically identify anomalies or patterns indicative of issues in the FIFO buffer.
- Predictive maintenance: Utilize Merlin AI to predict potential QSPI FIFO buffer failures based on historical data, enabling proactive maintenance and minimizing downtime.
-
Collaboration and Resolution:
- Collaborate with development teams: Engage with development teams to share findings and collaborate on implementing solutions to address the QSPI FIFO buffer issues.
- Implement recommended fixes: Apply any recommended fixes or patches suggested by both the development teams and Merlin AI insights to resolve the problem.
In summary, addressing the QSPI FIFO buffer issues on the TriBoard TC277 involves a comprehensive approach, including thorough debugging steps and the integration of Merlin AI for proactive monitoring and predictive maintenance. Collaboration between development teams and the application of recommended solutions are essential for a successful resolution.