Genesys 2 current measurement problem

[abdelmoughni]

Hello

I had recently my FPGA Genesys 2, my first project with this card is to measure the current using INA219AIDCNR with the I2C communication, I used the demo project as reference, except that in this project I want display the current calculation on a UART terminal and not on the OLED display. After several trying I can't achieve my objectives, despite the bitstream is created without errors and the FPGA is properly programmed.
I would appreciate any help to realize this project
you find enclosed with this message the block design schematic, XDC file and the program C.

XDC_file.xdc

design_1_1.pdf

test.c

[D@n]

How far along have you been able to debug what is going on?

Dan

[Billel]

Hi Mr Dan

I have changed only the program C, i have initialise the UART and the I2C peripheral as you suggested. You find attached the file C.

I hope that this can be helpful.

Thanks 

helloworld.c

[D@n]

Billel,

For the sake of others who may be struggling with this same problem, can you post the files that you changed?  For example, your (eventually) working C code, and your XDC file?

Thanks,

Dan

[Billel]

Hi again

I have solved the problem by initialise the I2C peripheral and ensure that I have correctly map the peripheral in the bloc design.
Thank you Mr Dan for your help.

[Billel]

Hi Mr Dan

I currently work on the program takes into consideration your suggestions, I try to use the terminal (xil_printf statements) to verify the different stages of the program.

[D@n]

You did get the demo working, right?  The demo that included a reading of the current?

So ... if the demo works, but after stripping out the cruft from the demo that you didn't need it stops working, wouldn't that mean that some of the extra stuff you stripped out was actually necessary to get it to work?

For example, I'm looking through the demo code to find what initializes the I2C driver, and I note that both the current measurement and the audio use the I2C port.  If you left the audio running, would the current measurement still work?  Or is there another device that, if you didn't remove the initialization for, would keep your current measurement device working?

Sorry if I seem all over the map here ... I'm just coming up to speed on this problem.

Dan

[D@n]

Okay, it took me a while, but I finally found the source code for fnGetINACurrent.

If you put the xil_printf("Hello ... back in to your test.c program, do you see Hello World\n on your terminal?

I'm going to assume you do, otherwise this gets a touch more difficult.  (It could be that your processor hangs somewhere in here, so the UART no longer works.  If that's the case, we'll need to force the program to output and stop, and then slowly move the stop towards where it's hanging to find the bug.) 

The next step will be to place xil_printf statements within ina.c, to find out where that fails.  So ... right before the first EXIT_ON_FAIL line, stuff a xil_printf of some type.  Do the same after the last EXIT_ON_FAIL line in the fnGetINACurrent function of ina.c.  If the I2C device doesn't respond at all, the first EXIT_ON_FAIL line should exit.  Shall we see if it does?

Dan

[Billel]

Yes Mr Dan this the only piece of code we have, include also the INA.h and INA.c. I have inspire this code frome the demo code of the board.

 

[D@n]

Billel,

Looking at the one piece of code I have, there's really not enough to go on.  Is that the only piece of source code to the whole project, the test.c file from above?  Or are there other pieces, such as the source code for fnGetINACurrent and such?

I only ask because it might be possible to do the "scope" work in software, but only if you have the source code for some more of those components you are using.

Thanks,

Dan

[Billel]

It would certainly be useful as information, thank you for your assistance Mr Dan.

[D@n]

It's not as bad a problem as you might think.  I don't have a license for a chip scope either, and yet I have managed to build a home grown scope.  Such scopes are actually fairly simple to write.  I'd recommend mine to you, but it connects to a wishbone bus instead of an AXI bus.

At any rate, you may need something like this to debug that I2C interaction.  The alternative would be to stare at your code and suddenly realize what was going wrong.  Since I'm not familiar with microblaze, nor am I familiar with the libraries you are using, that approach is rather difficult for me.

Dan

[Billel]

For the  "init_platform()" I already test it and past  successfully. I have also test the UART and it work fine. I will follow your suggestion to test the I2C using an LED.

For the current reader device it will be a problem to see what happened, because I don't have a license for the chipscope.

Thanks again Dan

 

 

[D@n]

Okay, but if we're going to figure out what's going on, we're going to need some more details.  This is one of the key parts of FPGA programming--getting the design to tell you what's wrong.

Can you tell me ...

1. Did your program ever gets past "init_platform()" successfully?

To test this, can you set an LED at this point?  Alternatively, you could output something to the UART as well ...

2. How far along did your program get?  What line did it hang on? 

You can use both UART and/or LEDs to answer this question.

3. Is the I2C port is properly connected?

Unless you've got a better option here, you might just wish to connect the I2C port to a pair of LEDs.  If both are always on, that would be passing the first test.

As a second test, turn each LED off any time their respective I2C port wire goes low.  You'll need to start a counter at the same time, and hold the LED off long enough to see that it turned off, however.

3. Is the current reader device is properly addressed?

To answer this question, you'll need to know whether or not the device acknowledges your I2C requests.  Realistically, at this point and in order to do this you will need some sort of internal scope, whether it be a chipscope or something else, internal to your design to watch the interaction and report back whether or not it is as desired.

I understand that these questions don't necessarily fit nicely into a canned design, but they are the sorts of debugging questions that are going to need to be answered to start identifying where the problem lies.

Dan

[Billel]

Thanks for your interest Dan.

I cannot see any error when I try to debug my program but without any result.

[Billel]

yes Dan same board

[D@n]

Are you also using the Genesys 2 and INA219AIDCNR?

Dan

[Billel]

Hello

I need to measure the current using the same board, but without any result, I need help for this subject?

Thank you all

[mwingerson]

I try to troubleshoot as much as I can in simulation since troubleshooting in hardware is slow and painful. It is a lot better using Chipscope, if you have a license.

Here is a demo for simulating a custom IP core in Microblaze. https://reference.digilentinc.com/zybo/custom_ip_simulation

It isn't exactly what you are trying to do but the steps on simulating a Microblaze project are there. In simulation you should be able to confirm the design and program.  Most importantly, you want to see that the IIC lines are changing as expected with your design and program. 

Then move to troubleshooting incoming data.  I would route incoming IIC data to the uart either in software or hardware.  Dealer's choice.

Best of luck!

Marshall

[abdelmoughni]

I'am still working on it but without any result until now.

[D@n]

Looking at your schematic, don't the IIC wires need to be both in and out?

Dan

 

[abdelmoughni]

Thanks a lot JColvin. I will wait for any help. 

[JColvin]

Hi abdelmoughni,

It's good to hear that you got the original demo project working correctly on the board, but I'm not sure what the issue you are running into is. My guess would be that there is something that you still need to include from the original demo, but I am not an FPGA expert by any means, so I personally don't know what it might be. I'll ask some of our applications engineers about this though to see if they can spot what you are running into.

Thanks,
JColvin

[abdelmoughni]

yes Dan before I start this project i have implemented the demo project on the board, i have also try a tutorial on implementing a simple "Hello world" project using microblaze (from Digilent) and it work correctly. The power LED also indicate that the board working proporely, even the LED that indicate the successful of the implementation also blinking properly when i implement my project.

[D@n]

Usually at this point I start working with LEDs then.  Do you have a simple instruction that can adjust LED's?  (Sorry, I'm not an expert with uBlaze.)  Set your LEDs to a known pattern  as your first instruction within main(). If your LED's switch to this pattern, you know your program loaded, started, and then failed.  If you can't set this pattern, then you know your program never loaded properly.

Does Xilinx have a uBlaze debugger you can load your program into?

You might also wish to scour any warnings given by ISE and the uBlaze compiler. 

How about the power LED.  Once you load the board, does the power LED remain on?  Does your board have a short circuit in it as a result of plugging in the current measuring system?  Did you plug the PMod in backwards?

Oh, and I forgot to ask, did you get the demo application running first before changing it?

Dan

 

[abdelmoughni]

hello Dan

for the moment I can not diagnose where the problem lies, I have a  bitestream that is created properly, the implementation is carried out without errors but I am still unable to read the current, even I can not print the line "Hello world" on the terminal.