Jump to content
  • 0

using third party C++ Library


Mehdim

Question

 

Hello all tech-lovers;

Do any of you guys have experience using Eigen library (http://eigen.tuxfamily.org/index.php?title=Main_Page) in  bared metal OS ?

When I try to define a matrix like :

       xil_printf(" TP CC 0 \r\n ");

       MatrixXd m1(6,6);

       MatrixXd m1_inv(6,6);

       xil_printf(" TP CC 1 \r\n ");

 

the program is compiled and built, but when running it on the board, it HALT happens!

I saw the assembly code of the line that exception happens, it is

0010da80:   ldr r0, [r0]

in which r0= 3758100524

 

 checklist.jpg

I think the halt is because of referring to the address( decimal: 3758100524, Hex: E000102C )which is out of range of the address bus of Zybo! However this code works fine on PC ( X86)

But I don’t know why my c codes convert to this assembly code.

I would appreciate if any of you guys have any hint or experience on that.

 

Link to comment
Share on other sites

12 answers to this question

Recommended Posts

Of all the places for the code you've written to die: in the I/O *read* function.

I really don't think this has anything to do with the C++ matrix library you are using.  I mean ... is the matrix library calling a function to read from I/O?

Why don't you take a look at how you've got your entire board configured.  Do you have, for example, a receive UART configured anywhere?

Dan

Link to comment
Share on other sites

Hello Dan;

Thank you for the prompt reply; this matrix library is a part of, I think, OpenCV which is commonly used in C++ for Matric operation.

I initialize the matric by other values(not from board IO):

      

       for (i=0; i<xl; i++)

       {for (j=0; j<xl; j++) {m2(i,j)=Cxx[j];}}

 

       m2_inv = m2.inverse();

 

       for (i=0; i<xl; i++)

       {for (j=0; j<xl; j++) {invCxx[j]=m2_inv(i,j);}}

All peripherals if the board work fine.

Link to comment
Share on other sites

If all peripherals on the board work fine, ... then why is it halting in the middle of Xil_In32 in the disassembly you posted with your original question?

If you are certain the bug is in the matrix math, then it may help to rebuild the matrix routine you are using and place some sort of indicator function within it, and then see how far it goes.  (You might also manage this with the debugger, if the stack hasn''t get corrupted ...)  Another possibility might be to change an LED at certain points within the library code and then to see if and where the LED changed.  That should allow you to help track down the bug.  Still ... I'm voting for a peripheral problem ...

Dan

Link to comment
Share on other sites

I do really appreciate your comment;  but iI think it is related to some memory issue. you know it is trying to access the address  3758100524 which is not peripheral. my vote goes for  "violation in memory access"; maybe  the address 3758100524  is out of memory range of the Zybo board; but I dont know how to track this issue

Link to comment
Share on other sites

You might wish to check out the Zybo reference manual: page 6 discusses how peripherals can use memory mapped I/O.  In other words, those peripherals using memory mapped I/O will actually respond to a memory read or write request as though they were memory, but often with side effects attached.  I'm sure if you dig further, you'll discover more of the details of how this is done.

Dan

Link to comment
Share on other sites

Hi again;

What I am thinking is that maybe it is because of GCC that make binary file. It is possible that GCC makes wrong binary files which refers to memory location which does not belong to ARM A9.

Would you please let me know which GCC you usually use for Zynq-700 with ARM A9 architecture?

ARM9.png

as you can see, there is not ARM A9 GCC in SDK list.

Link to comment
Share on other sites

Hi Mehdim,

Based on this other thread in our Forum, you will need to use the mig.prj file to get the DDR3 memory incorporated into your design since it is not included in the .xdc file by default (see the last comment in the linked thread for the reasoning behind this). As for your other question, I have asked some of our applications engineers about it; they will get back to you here on the Forum.

Thanks,
JColvin

Link to comment
Share on other sites

Hi Mehdim,

I'm sorry but i do not have any experience with the Eigen library. When trouble shooting i usually use a xil_printf.  Also we use the default compiler in SDK for the Zynq-700 with ARM A9 architecture as shown below(SDK 2016.2).  

thank you,

Jon 

toolchain_escalation.jpg

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...