Forum Discussion

AShiv's avatar
AShiv
Icon for New Contributor rankNew Contributor
7 years ago

Strange Issue with DE0-Nano-SoC FPGA=>HPS Data Transfer

Hi Everyone,

Running into a strange issue with data transfer from the FPGA=>HPS Bridge Data transfer. I am using an Avalon-MM Pipeline Bridge to transfer 32-bit data chunks across the bridge. I have done this before, but am by no means an expert. What is happening is the bridge succesfully writes 31 times, then the HPS crashes everytime. No matter where the write is occuring (I'm writing to 0x2800_0000-0x28FF_FFFF) But as soon as it writes to 0x2800_007E or whereever the 31st write occurs, the waitrequest from the bridge comes high and the HPS completely freezes, almost like the FPGA wrote to some key piece of RAM. The HPS program keeps running, but when I Ctrl-C out of it, the HPS refuses to accept any other commands and will also sometimes print out a giant error message that looks like this: 

INFO: task kjournald:46 blocked for more than 120 seconds.
      Not tainted 3.13.0-00298-g3c7cbb9-dirty #8
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kjournald       D 80586a00     0    46      2 0x00000000
[<80586a00>] (__schedule+0x234/0x5fc) from [<80586ebc>] (schedule+0x40/0x90)
[<80586ebc>] (schedule+0x40/0x90) from [<80586f84>] (io_schedule+0x78/0xa4)
[<80586f84>] (io_schedule+0x78/0xa4) from [<801421e8>] (sleep_on_buffer+0x18/0x20)
[<801421e8>] (sleep_on_buffer+0x18/0x20) from [<80587604>] (__wait_on_bit+0x84/0xc8)
[<80587604>] (__wait_on_bit+0x84/0xc8) from [<805876c0>] (out_of_line_wait_on_bit+0x78/0x80)
[<805876c0>] (out_of_line_wait_on_bit+0x78/0x80) from [<801421cc>] (__wait_on_buffer+0x34/0x38)
[<801421cc>] (__wait_on_buffer+0x34/0x38) from [<801f8bf4>] (journal_commit_transaction+0x79c/0x1750)
[<801f8bf4>] (journal_commit_transaction+0x79c/0x1750) from [<801fd6f4>] (kjournald+0x110/0x2c0)
[<801fd6f4>] (kjournald+0x110/0x2c0) from [<800452a0>] (kthread+0xe4/0xf8)
[<800452a0>] (kthread+0xe4/0xf8) from [<8000ef18>] (ret_from_fork+0x14/0x20)
INFO: task sh:182 blocked for more than 120 seconds.
      Not tainted 3.13.0-00298-g3c7cbb9-dirty #8
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
sh              D 80586a00     0   182    174 0x00000001
[<80586a00>] (__schedule+0x234/0x5fc) from [<80586ebc>] (schedule+0x40/0x90)
[<80586ebc>] (schedule+0x40/0x90) from [<80586f84>] (io_schedule+0x78/0xa4)
[<80586f84>] (io_schedule+0x78/0xa4) from [<801421e8>] (sleep_on_buffer+0x18/0x20)
[<801421e8>] (sleep_on_buffer+0x18/0x20) from [<805873f0>] (__wait_on_bit_lock+0x7c/0xc8)
[<805873f0>] (__wait_on_bit_lock+0x7c/0xc8) from [<805874b4>] (out_of_line_wait_on_bit_lock+0x78/0x80)
[<805874b4>] (out_of_line_wait_on_bit_lock+0x78/0x80) from [<801429f4>] (__lock_buffer+0x44/0x48)
[<801429f4>] (__lock_buffer+0x44/0x48) from [<801f7bd0>] (do_get_write_access+0x3cc/0x454)
[<801f7bd0>] (do_get_write_access+0x3cc/0x454) from [<801f7dd8>] (journal_get_write_access+0x34/0x48)
[<801f7dd8>] (journal_get_write_access+0x34/0x48) from [<8019731c>] (__ext3_journal_get_write_access+0x30/0x60)
[<8019731c>] (__ext3_journal_get_write_access+0x30/0x60) from [<80184840>] (ext3_reserve_inode_write+0x64/0x8c)
[<80184840>] (ext3_reserve_inode_write+0x64/0x8c) from [<801848b0>] (ext3_mark_inode_dirty+0x48/0xac)
[<801848b0>] (ext3_mark_inode_dirty+0x48/0xac) from [<801880cc>] (ext3_dirty_inode+0x68/0x90)
[<801880cc>] (ext3_dirty_inode+0x68/0x90) from [<8013ac98>] (__mark_inode_dirty+0x58/0x2dc)
[<8013ac98>] (__mark_inode_dirty+0x58/0x2dc) from [<8012a370>] (update_time+0x7c/0xc0)
[<8012a370>] (update_time+0x7c/0xc0) from [<8012a62c>] (touch_atime+0x180/0x18c)
[<8012a62c>] (touch_atime+0x180/0x18c) from [<800c6b7c>] (generic_file_aio_read+0x3fc/0x800)
[<800c6b7c>] (generic_file_aio_read+0x3fc/0x800) from [<801106ac>] (do_sync_read+0x94/0xbc)
[<801106ac>] (do_sync_read+0x94/0xbc) from [<80111270>] (vfs_read+0xac/0x13c)
[<80111270>] (vfs_read+0xac/0x13c) from [<801164e4>] (kernel_read+0x44/0x50)
[<801164e4>] (kernel_read+0x44/0x50) from [<801165bc>] (prepare_binprm+0xcc/0x124)
[<801165bc>] (prepare_binprm+0xcc/0x124) from [<80117be4>] (do_execve+0x3f4/0x60c)
[<80117be4>] (do_execve+0x3f4/0x60c) from [<8011806c>] (SyS_execve+0x40/0x54)
[<8011806c>] (SyS_execve+0x40/0x54) from [<8000ee80>] (ret_fast_syscall+0x0/0x30)

I am completely lost, this FPGA write is the only thing connected to the HPS so it has to be something with it but I have no idea what I am doing wrong. Attached is also a brief print out of the signal tap, as well as my QSys setup. I'd appreciate any suggestions as I am at a total loss, especially since it crashes at the 31st write, no matter what address I write to, and if I write to the same address in the HPS using memtool from the command line there is no issue. Thanks!

4 Replies

  • Daixiwen's avatar
    Daixiwen
    Icon for Occasional Contributor rankOccasional Contributor
    7 years ago

    Could it be that the bridge doesn't like unaligned accesses? Have you tried with addresses multiple of 4? I didn't think it would even work correctly with unaligned accesses. (it doesn't in a Nios2 system at least).

  • AShiv's avatar
    AShiv
    Icon for New Contributor rankNew Contributor
    7 years ago

    Hi Daixiwen,

    So, I've changed my design a bit so that it now uses the F2SDRAM bridge since I don't need cacheable access. The bridge now goes high at exactly 17 writes every time, but only the first write actually goes to the DDR3, even though the subsequent 16 writes say they go through. In that system I tried changing it so its a multiple of 4 address, but that did not make a difference. I'm not sure what I am doing wrong here...

  • Daixiwen's avatar
    Daixiwen
    Icon for Occasional Contributor rankOccasional Contributor
    7 years ago

    I'm not sure what is going on either. I have never used the F2SDRAM bridge before but have several designs with the F2H bridge that work very well.

    I assume that you enabled and configured the bridges from the HPS side? You need to be sure you recompiled and reflashed the preloader after you made your modifications in QSys to be sure the bridges are configured correctly, and if I remember correctly they are still not enabled automatically and you need to do it from the HPS software. From my experience trying to use an uninitialised bridge will freeze the Avalon bus but keep the HPS system running.

    How much RAM do you have? Did you check that the address that you use is a physical address and not an address remapped elsewhere by the MMU? The bridges won't go through MMU remapping. Those could be stupid questions but I can't think of anything else right now.

  • AShiv's avatar
    AShiv
    Icon for New Contributor rankNew Contributor
    7 years ago

    I've done the preloader/uboot flash, but I don't think I did anything to configure the bridges from the HPS software, and I wasn't aware that anything needed to be done from that side. I have 1gigabit of DDR3, I malloc'd a section of memory for this task and passed the pointer to the FPGA from the HPS side. I don't think the address was a remap, but I am not positive.

    Do you know if I have to create a new device tree ?