[FPGA][BLE][Pmod] Zybo Z7-10 komunikacja bluetooth z wykorzystaniem PMOD BLE

[bridzysta]

Cześć,

chciałbym prosić o pomoc w kwestii podpięcia modułu Pmod BLE do płytki Zybo Z7-10.

Opis projektu

Chciałbym podłączyć Pmod BLE do płytki Zybo Z7-10. Chciałbym by testowa aplikacja mogła wysyłać i odbierać dane po bluetooth (do testowania chciałbym użyć jakiejś aplikacji z AppStore). Na początku mogłoby to być wysyłanie zwykłego ciągu znaków, jak np: "Cześć Zybo" i "Cześć telefon" czy coś podobnego.

Próby podłączenia

Znalazłem podobny przykład w intrnecie (tutaj -> link autorstwa osoby o nicku: ralphjy). Próbowałem odtworzyć projekt, który opisał w tym artykule jednak nie udało mi się to. Poniżej zamieszczam swój block diagram, który jest podobny do tego który prezentuje ralphjy.

Dołączam jeszcze constraints mojego projektu. Niestety nie wiem jak dokładnie powinny być one podpięte. Na końcu problemu zamieszczam link do constraint dla Zybo.

Oczywiście próbowałem wygenerować bitstreama, ale bezskutecznie :(.

Może ktoś z Was miał już do czynienia z modułem Pmod BLE i byłby w stanie pomóc :)? Btw. dzięki wielkie za jakiekolwiek wskazówki!

Sprzęt

• Zybo Z7-10 -> link
• Pmod BLE -> link

Software

• Zybo-Z7 Constraints -> link
• pliki źródłowe Pmod BLE-> link

[piotr96]

Tak, na szybko, to pierwszy, widoczny na pierwszy rzut oka błąd, to nazwa wejścia reset_rtl. Na diagramie jest to właśnie reset_rtl, a w pliku z przypisaniem pinów jest dołożona końcówka _i (reset_rtl_i). Popraw to, tak, żeby było jednakowo w obydwu miejscach.

Drugi komunikat o błędzie wynika prawdopodobnie z faktu, że Vivado nie wie, których pinów chcesz użyć dla sygnałów uart_rtl_rxd i uart_rtl_txd. Jeżeli jest to cała zawartość pliku xdc, to nie wiem, na jakiej podstawie Vivado dokonuje mapowania pozostałych sygnałów na konkretne piny I/O układu. Spróbuj dla testu dodać do tego pliku dwie dyrektywy set_property PACKAGE_PIN (tak, jak zakomentowane wiersze widoczne na zrzucie ekranu) dla tych sygnałów uart_rtl.

Ale na podstawie widocznych również ostrzeżeń wydaje mi się, że powyższe nie rozwiąże wszystkich problemów (ostrzeżenia dotyczą również początku pliku xdc). Bez spojrzenia na całą zawartość Twojego pliku, ciężko coś wyrokować.

[bridzysta]

Cześć @piotr96 dzięki za podpowiedzi :).

Wspomnianą uwagę odnośnie resetu poprawiłem (zmieniłem nazwę w pliku z constrainami). Podsyłam też cały plik byś mógł zerknąć na zawartość. Może coś uda Ci się znaleźć?

Poniżej screen rezultatów po próbie wygenerowania bitstreama (poprawka wspomniana wyżej). Implementacja i synteza przeszła.

constraints.zip

[piotr96]

Tak, jak wspominałem w drugim akapicie posta powyżej, Vivado nie wie, które piny układu chcesz wykorzystać jako poszczególne sygnały. Domyślam się, że początek pliku XDC jest od producenta płytki, a końcówka skopiowana z innego źródła – w takiej formie, to nie ma prawa działać.
W niektórych sytuacjach, gdy używasz konkretnego „elementu" zaszytego w układzie, Vivado jest w stanie przyporządkować Twój sygnał do konkretnego pinu układu FPGA. Korzystając z pinów ogólnego przeznaczenia, to przyporządkowanie może być zrobione w sposób losowy, jeżeli nie wyspecyfikujesz tego w pliku XDC.
W Twoim przypadku, najlepiej wyspecyfikować, które piny chcesz użyć – wpisać ich standard napięciowy oraz konkretną literkę z liczbą, oznaczającą nóżkę układu FPGA. Na przykład, domyślam się, że chcesz użyć pierwszego pinu złącza JA. W tej chwili masz to zrobione w ten sposób:

##Pmod Header JA (XADC)
set_property -dict { PACKAGE_PIN N15   IOSTANDARD LVCMOS33 } [get_ports { ja[0] }]; #IO_L21P_T3_DQS_AD14P_35 Sch=JA1_R_p
...
set_property IOSTANDARD LVCMOS18 [get_ports ja_pin1_io]

Jest to bez sensu. W pierwszej dyrektywie tworzysz sygnał (wektor) nazwany ja, jego najmłodszy bit przypisujesz do pinu oznaczonego N15 i ustawiasz standard napięciowy 3,3V.
W drugiej dyrektywie tworzysz pojedynczy sygnał ja_pin1_io, ustalasz dla niego standard napięciowy 1,8V i nie przypisujesz do żadnej nóżki układu.

Jeżeli zależy Ci na tych 1,8V, to musisz sprawdzić, czy w ogóle te piny mogą pracować w takim standardzie i pod jakimi warunkami. Jeżeli zaś 3,3V jest akceptowalne, to ta druga dyrektywa powyżej jest do usunięcia.

W przypadku sygnałów wymienionych w komunikacie o błędzie (uart_rtl_rxd, uart_rtl_txd, reset_rtl) Vivado nie wie, do których pinów FPGA chcesz te sygnały podłączyć. Musisz to wyspecyfikować w sposób, jak w pierwszej, przytoczonej wyżej dyrektywie (czyli używając PACKAGE_PIN).

Pamiętaj, że nazwy sygnałów w pliku XDC oraz w Twoim BD (Block Diagram) muszą być identyczne.

Ja na Twoim miejscu usunąłbym ostatnie wiersze pliku XDC, a wykorzystałbym to, co daje producent płytki.
Czyli znowu przykład (jest to też opisane u góry pliku XDC), zakładając, że sygnał uart_rtl_rxd chcesz wyprowadzić na pierwszy pin złącza JD, to:
1. Odnajdujesz odpowiedni wiersz w pliku XDC:

#set_property -dict { PACKAGE_PIN T14   IOSTANDARD LVCMOS33     } [get_ports { jd[0] }]; #IO_L5P_T0_34 Sch=jd_p[1]

2. Zmieniasz nazwę sygnału:

#set_property -dict { PACKAGE_PIN T14   IOSTANDARD LVCMOS33     } [get_ports { uart_rtl_rxd }]; #IO_L5P_T0_34 Sch=jd_p[1]

Zwróć uwagę też na wiersze 8 i 9, w których jest „tworzony" sygnał zegarowy, nazwany sysclk. Jeżeli chcesz z niego skorzystać w projekcie, to musisz ujednolicić nazwę w pliku XDC, z tym, co jest w BD.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[bridzysta]

Hej @piotr96 coś się udało :). Zmieniłem po Twoich sugestiach plik xdc (dorzucam plik ze zmianami). Synteza, implementacja i wygenerowanie bitstreama przeszły pomyślnie!

Następnie podczas próby wgrania programu (PmodBLE_v1_0/examples/main.c -> link) podczas "Program FPGA" pokazał się komunikat (warning poniżej). Nie jestem w stanie uruchomić programu :(.

constraints.zip

[bridzysta]

Jeszcze jedna uwaga @piotr96.

Udało się skompilować program i wgrać (Program FPGA; niestety znowu pojawił się ten sam komunikat co wyżej), natomiast podczas próby uruchomienia programu (Run -> Launch on Hardware) pojawił się error jak poniżej. Przeczuwam, że to problem z połączeniem płytki. Próbowałem z różnymi kablami microUSB ale czasem ma problem ze złapaniem połączenia.

[piotr96]

Niestety, nigdy nie uruchamiałem Microblaze, więc nie pomogę w tym przypadku. FPGA możesz też spróbować zaprogramować (wgrać bitstreama) z poziomu Vivado (Hardware Manager).

Edytowano Wrzesień 5, 2022 przez piotr96

[Elvis]

@bridzysta Używanie Microblaze na płytce Zybo to trochę nietypowe rozwiązanie, ale powinno działać poprawnie. Próbowałeś zacząć od prostszego projektu, np. z samym procesorem, ale bez peryferiów?

[Elvis]

Właśnie próbowałem uruchomić taki minimalny projekt i to jednak tak łatwo nie zadziała. Jednak Zynq to nie Spartan, nawet jeśli chcemy używać Microblaze, trzeba chyba skonfigurować ARM.

Proponuję zamiast męczyć się z Microblaze po prostu użyć wbudowanych rdzeni Cortex-A9. Będzie łatwiej i szybciej 🙂 A w przyszłości zawsze możesz dodać Microblaze jeśli będzie potrzebny.

[Elvis]

Poniżej na szybko wyklikany projekt z PmodBLE dla płytki Zybo:

Nie mam niestety modułu BT, więc jeszcze nie testowałem działania, ale może później się uda. W każdym razie projekt syntetyzuje się bez problemu, pliki XDC nie są potrzebne.

[Elvis]

Moduł w końcu dotarł, więc mogłem przetestować działanie PmodBLE 🙂

Jak chodzi o projekt w Vivado to zmieniłem podłączenie na JE. Złącze JA jest domyślnie przeznaczone dla ADC - nie sprawdzałem schematów, ale na wypadek jakby tam były jakieś dzielniki, bufory, czy inne cuda wolałem wybrać coś "neutralnego". złącza JB-JD są przeznaczone dla szybkiej komunikacji, a dopiero JE to standardowe podłączenie do PL, więc wydawało mi się bezpiecznym wyborem.

Przykłady od producenta prawie działają, tzn udało mi się coś takiego uruchomić:

#include <stdio.h>
#include "platform.h"
#include "xil_printf.h"
#include "xgpio.h"
#include "sleep.h"
#include "PmodBLE.h"

#define BLE_UART_AXI_CLOCK_FREQ 50000000

PmodBLE myDevice;
XGpio gpio;

int main()
{
	char buf[81];
	int n = 1;

    init_platform();

    XGpio_Initialize(&gpio, XPAR_GPIO_0_DEVICE_ID);
    XGpio_SetDataDirection(&gpio, 2, 0x00);

    BLE_Begin (
        &myDevice,
        XPAR_PMODBLE_0_S_AXI_GPIO_BASEADDR,
        XPAR_PMODBLE_0_S_AXI_UART_BASEADDR,
        BLE_UART_AXI_CLOCK_FREQ,
        115200
    );

    print("Hello World\r\n");

    while (1) {
    	sprintf(buf, "Hello World! %d\r\n", n++);
    	BLE_SendData(&myDevice, (u8*)buf, strlen(buf));

    	XGpio_DiscreteWrite(&gpio, 2, 0x01);
    	usleep(500000);

    	XGpio_DiscreteWrite(&gpio, 2, 0x00);
    	usleep(500000);
    }

    return 0;
}

Na telefonie pojawiają się dane i chyba o to chodziło 🙂

Natomiast jest problem z odbieraniem danych. Czasem to działa, ale ogólnie dość słabo... Po wyłączeniu delay-ów i tylko odsyłaniu odebranych danych, wygląda jakby odbierało po jednym bajcie. Nie przyglądałem się szczegółom, więc pewnie da się to poprawić.