You are not logged in.
When i use sdk 14.7 to build the 802.11 ref design v1.3.0 project , some problem happened,for example, can't find xparameters.h file.
can you tell me how to solve this problem ?
Looking forward to your reply,thank you.
Offline
We do not recommend using SDK 14.7 with the 802.11 reference design. There are known issues in the compiler using -Os, which is the default optimization used in the 802.11 reference design. The 802.11 reference design was written and tested on SDK 14.4, which is what we recommend and if you have a license for SDK 14.7, that license will work with the SDK 14.4 tools.
That being said, xparameters.h is part of the BSP. When you change versions of the SDK, you must re-build the BSPs (i.e. the BSPs that are part of the release are built using SDK 14.4). Just make sure that you transfer all the settings from the original BSPs over to the new ones you create for the SDK 14.7 release.
Offline
OK,thank you.
When I debugging the progect,like debugge the "wlan_mac_high_ap" project, I find that the "WARP-AP" network can't be detected by my phone. However,when I just program the project to FPGA, it can be detected,and it will display "1" which shows that it has been associated with my mobile phone successfully.
So can you tell me the reason about the phenomenon?
Offline
You need to be more specific about how your debug project is setup. What bitstream did you use to configure the FPGA? Was the CPU Low application included in the bitstream? Do you see the CPU Low UART print normally post-configuration? When you load the CPU High application via the debugger what does its UART print? You can switch between UARTs via the DIP switch - refer to the user guide.
Offline
OK,The debugging process is carried out in accordance with the introduction to this post,http://warpproject.org/forums/viewtopic.php?id=2875. Before this process, I program the project to FPGA and make sure the project worked well. The bitstream and BMM file are all included in the subfolder \Mango_802.11_RefDes_v1.3.0_hw_platform.The software configuration contains mb_high(wlan_mac_high_ap.elf) and mb_low(wlan_mac_low_dcf.elf).
After the start of the debugger,The UART of the CPU High prints as follows:
"DRAM SODIMM Detected
Tx Queue of 3413 placed in DRAM: using 13652 kB
Initializing Event log (1044664320 bytes) at 0xC1BBB000
BSS Info list (len 768) placed in DRAM: using 60 kB
1 Eth Tx BDs placed in BRAM: using 64 B
239 Eth Rx BDs placed in BRAM: using 14 kB
XTmrCtr failed to initialize
waiting on cup low to boot"
Then it will enter an infinite loop, "void Xil_Assert(const char *File, int Line)
{
***********************
while (Xil_AssertWait) {
}
***********************
}"
When i toggle the DIP switch to Check the CPU Low information, however, It shows nonthing.
Last edited by liuyi (2015-Oct-04 09:13:41)
Offline
Did you select 'bootloop' as the application for CPU High when you programmed the FPGA? If not, the debugger will try to re-load an application into the CPU when the CPU is already running that application. This can lead to unexpected behaviors like the ones described above.
Offline
Hello,murphpo
Yes,I have selected "wlan_mac_high_ap.elf"for the mb_high and "wlan_mac_low_dcf.elf" for the mb_low every time ,and progreamed them to FPGA before start debugging.
I also have a question about this issue,How is a interrupt is triggered?for example, as we all know the beacon frame is transmitted by cycle,I believe there bust be one timer for it ,When the timer count to zero,the inteerupt will be triggered,and the it will turn to corresponding interrupt handler,and then it calls the function"beacon_transmit" which lies in wlan_mac_ap.c
Offline
I'm not quite sure I understand the question. There are many different interrupts in the system, each with their own trigger conditions.
If you look in wlan_mac_ap.c, you can see that the reference design uses the scheduler in order to set up periodic beacon transmissions. The scheduler uses a timer and interrupts as part of its ability to execute scheduled events.
The "Search" --> "File..." dialog in the SDK is very useful when looking for how functions are connected when you use "File name patterns" = "*.h, *.c". By looking up the name "beacon_transmit" you can see where it is defined and called within the framework.
Offline
Thank you for your reply.Your answer was just what I want. There is still a problem I have not been solved, As described above in the #3 and #5 floor,can you tell me why it will enter an infinite loop? the function prototype lies in /wlan_bsp_cpu_high/mb_high/libsrc/standalone_v3_08_a/src/xil_assert.h.
Last edited by liuyi (2015-Oct-05 20:37:53)
Offline
You have entered an error condition. If you look at the print out: "XTmrCtr failed to initialize" is an error message from the scheduler initialization (I apologize that the error message could be clearer). Since, the timer instance was not initialized, when the code enables the scheduler, the scheduler interrupt handler checks the timer instance and then enters an infinite loop since it can not properly execute (i.e. the Xil_AssertVoid line).
If you load the FPGA properly for debugging (i.e. load CPU low with an appropriate project and CPU high with bootloop); download the CPU high code via the debugger; then when you press "Play" in the debugger, everything should work and initialize properly. As murphpo said, there are unexpected behaviors when you try to re-load an application into the CPU when it is already running that application.
Offline
According to what you have said,I have solved the problem.The cause of the problem is that what you said above.Thank you.
Offline