TM4C1294NCPDT: tm4c1294 how to load fpga

user4766611

Part Number: TM4C1294NCPDT

we use arm load fpga.bin from flash , arm send the fpga.bin to the fpga to initiate fpga.

there is one FPGA(7A200T), one ARM(tm4c1294),one FLASH(N25Q)in our board.

1. arm connect with flash, fpga connect with arm;
2. fpga configration mode[111], slave serial;
3. power on, arm set program_b high, then low, set high again , arm read the init_b, the value is high.
4. arm read fpga.bin from the flash, and send the packet to the fpga use spi, the packet is 1024byte each time, the fpga.bin is 7MB;
5. arm finish the send packet, find the done signal is low always.

which step is error? give me some suggestion,thanks.

over 5 years ago

0 cb1_mobile over 5 years ago

Guru 117850 points

Would it not prove useful to employ 'KISS' - and:

send (far less) than '7MB' - and determine if that 'much, much smaller' data transfer succeeds? (between MCU & FPGA ... btw 7Mb appears more likely than 7MB)
Can you not 'monitor & confirm' the 'success or failure' - of each of your 'SPI Packets?' Is it not useful to 'catch' the first occurrence of 'issue or error?'
have you monitored all signals between MCU and FPGA? Are they all, 'to spec?'
does this issue occur upon, 'More than a single board?' What percentage of boards - exhibit this issue?
has this design (ever) succeeded? Have you employed that (exact) FPGA in the past - and succeeded? (if so - focus upon that which appears 'different' between past (ok) & present (failing).)
what are the consequences of your 'done' signal remaining low? Are you able to 'read any' of the FPGA's content? (if so - is that content correct?)
it proves - most always - highly useful to 'S L O W' the data transfer rate - so that the transfer enjoys the 'greatest odds' of success
KEY Scope Caps (absent from your report) provide the 'BEST' means to properly diagnose such issue. All critical signals (and timings) should be clearly presented. (signals should be well labeled!)
an active (and recently confirmed) 'link' - to the FPGA's data sheet - is "standard procedure." Unnecessary 'over-work' of your helpers - proves NOT to your advantage...

Note that it is 'your' responsibility to manage (both) the HW & SW interface between MCU & FPGA.

You 'finish' by asking, 'Which step is (in) error?' As you have sole possession of your board - should not you (uniquely) be able to:

confirm that the data retrieved from the flash memory - by the MCU - is correct?
confirm that the data being then being 'sent' by the MCU - 'matches' that data stored w/in your flash memory?
confirm that the FPGA's 'handshakes' are w/in spec - and proper - throughout the entire data transfer process

Your adoption of such 'checklist' - should enable you - to best, 'Answer your own question' - is that not so? (as your helper crüe here - have ZERO Access to your results - as, 'check-listed!')

0 Ralph Jacobi over 5 years ago

TI__Guru*** 128255 points

Hello,

There really isn't enough detail here for us to even try and offer advice... if you could address some of cb1's queries, one of us may have a better chance to be able to identify possible issues. The more detail you can offer about when the failure occurs and what the failing behavior is, the better chance we have to help.

0 user4766611 over 5 years ago in reply to Ralph Jacobi

Intellectual 380 points

thanks.

confirm that the data retrieved from the flash memory - by the MCU - is correct?
- arm read each packet from the flash, send the packet to the fpga using spi and to the pc using the ethernet, the pc shows the data is correct.
confirm that the data being then being 'sent' by the MCU - 'matches' that data stored w/in your flash memory?
- yes it is the same .
confirm that the FPGA's 'handshakes' are w/in spec - and proper - throughout the entire data transfer process
- i am not sure it .
  maybe ,the arm send packets to the fpga using the spi , spi should be always enable.
  - the tm4c1294 has only 256KB sram, So i cannot put the 7MB file in the ram , I must put smaller data in the ram, the SPI clk is disabled , when I put the data in the ram.

0 cb1_mobile over 5 years ago in reply to user4766611

Guru 117850 points

Thank you - yet for 'speeded & eased' diagnostic purpose - you have not (yet):

provided the requested scope-caps - of ALL key/critical signals - between the MCU and FPGA - during the transfer to the FPGA
provided a link (again requested) to your FPGA's data sheet
provided (any) response to the 'success or failure' - of the 1024 sized 'packets' - sent from MCU to the FPGA

It would prove of immense help - if it could be determined if (any) of those 1024 sized packets had 'succeeded.' And - if not - a far smaller packet should be created - and tested - to speed/ease the determination of 'just when' and 'why' such MCU -> FPGA transfer fails...

You must note that we are (likely) thousands of miles apart - and must (critically) rely upon 'you' - to serve as our 'eyes & ears' - so that we enable our best chance for success. Your compliance w/the (twice) listed requests - (really) is required...

And - note that earlier (w/in your initial post) you noted, "Which step is (in) error? Provide some suggestion, thanks."

Now you listed five steps - yet by the nature of your question - it appeared that you had not tested (any) of those steps. (as you did not know - which (if any) steps were in error.) Yet your 2nd posting indicates that you (had or now have) completed such (testing of those five steps) and that only the transfer from MCU to FPGA - remains 'Questionable.' Is this understanding correct?

If so - the need for clear (well labeled) scope captures, a working link to the FPGA's data sheet, and your report of (any) success when transferring 'far smaller' packets (i.e. 64 - 128 byte packets) - proves necessary to further assist you.

0 user4766611 over 5 years ago in reply to cb1_mobile

Intellectual 380 points

thanks , i will try again follow your guidelines.

Arm-based microcontrollers

Arm-based microcontrollers forum

TM4C1294NCPDT: tm4c1294 how to load fpga