I have written a small testing app to control the GPIO Pins of the Lime Mini. This works as advertised for the Lime Mini 1.0, but the Lime 2 seems to be different. I have not yet soldered the GPIO header on the Lime Mini 2, but from looking at the schematics I can see that there are already LEDs connected to the various GPIO pins. However none of the LEDs can be lit by poking into the registers, as is working for the Lime 1.
What do I miss here? In particular I am interested in the interworking of GPIO with the TX/RX Led for using it as a PTT switch for an external PA.
Ok, thank you. I already knew this page. However what I do not understand: If I set GPIO7 to a high value, why will the red LED not light up? Do I need to do something special to either have the GPIO connected to the RX/TX or beeing able to “manually” control the pins? Why will opening the solder bridge change things? Is this something the start up code is managing?
I also tried to light the LEDs by using LimeSuiteGUI with bord controls, But no I was not able to turn the LEDs on or off although in the schematics I can see they are wirded to the GPIOs,
If you want to use GPIO header I suggest you to use GPIO[3:0] pins because they are not shared with LEDs and there shouldn’t be any difference on controlling them on both v1 and v2 boards.
As you already spotted there are slight differences between v1 and v2 versions. In v2 version GPIO[7:4] are shared with LEDs and current FPGA gateware uses them to indicate status. In order to control GPIO[7:4] in v2 version you have to change some additional register values, check 0x00C0, 0x00C4, 0x00C6 register description in LimeSDR-Mini_Gateware_Description_V01r00.pdf document page 19.
Ah, yes, thank you so much! I guess you mean the BOARD_GPIO_OVRD register? There is no dedicated function in the API available yet, correct?
Btw.: Can you pls. point me to where the behaviour of the “dedicated functions” of the shared Pins is described or give me a short description? Particularly I am interested in suitability of the GPIO7 pin for PA control. I can see that the LED starts to give a short flash when I schedule a transmit package that has a waiting timestamp, and then when the time has come to actually transmit, the LED starts a steady light until the burst has finished. What puzzles me: Can I get rid of the spurious flash at the begin?
Yes, BOARD_GPIO_OVRD register overrides GPIO functions and gives control to the user.
Default GPIO behavior:
GPIO[3:0] - currently they don’t have any dedicated function and by default can be controlled by user.
GPIO4 - is shared with FPGA_LED2_G and indicates stream data from FPGA going trough USB.
GPIO5 - is shared with FPGA_LED2_R and LED is always off.
GPIO6 - is shared with FPGA_LED3_G and LED is always off.
GPIO7 - is shared with FPGA_LED3_R and indicates stream data from Host going trough USB to FPGA.
So GPIO7 indicates stream data going trough USB endpoint this is why you see “short flash” when you send packet with waiting timestamp.
If you are willing to do some testing I can add transmit indication to one of the GPIOs which should be more suitable for PA control.
This sounds great! We are, however, in design stage and have only an early prototype available. So what output would you expect from our testing, besides whether it works for us or not?
Finally after some delay, my friend told me that it looks like working but I have not yet managed to update/flash my mini and test it since I am still waiting for delivery of my GPIO header connectors.
He, however, succeeded by loading the bit file via LimeSuiteGUI. Is this the recommended approach? Shall we also load the golden file?
