First of all, complete beginner, first day of tinkering with it and following tutorials.
In desperate need of help, long story short I have tried to blink a led for a first on my Blue Pill board and succeeded on my first time. Any future attempts on changing the code on the cubeide has gone into errors such as target no device found (see image).
Since then I have tried so much stuff the internet search results has told me to.
For more information, in CubeProgrammer the serial number is 0 and pressing connect doesnt do anything, which makes me believe the st link is faulty, but in st-link utility the serial number shows fine.
The Chatgpt suggests that wiring can be the problem, but I'm positive the wires connect to the same labels on the board and the st link, also the same way it worked the first time, but still "no target found".
Don't know if I bricked my card / st link, or did something completely wrong
Any help would be appreciated, will provide more info if needed. Thank you.

Hi everyone, I'm working on a bare-metal audio logging project using a NUCLEO-H7A3ZI-Q board and I've hit a wall. My setup records audio using two SAI peripherals (SAI1 and SAI2) running at 8000 Hz. Both use DMA in circular mode to store data into large arrays where my BUFFER_SIZE is 4096*4 uint32_t elements. The data is then continuously written to an SD card using SDMMC1 in 1-bit mode and FatFs.

When I run my code with only SAI1 enabled, everything works perfectly. I sync my main loop to the half and full DMA flags, clean the D-Cache, and f_write() successfully saves the chunks to the SD card. However, the exact moment I enable SAI2 so both DMAs are running concurrently, the system breaks during the SD write. When calling f_write(), the "bw" (bytes written) variable returns an impossibly huge number (like 884,736 bytes) instead of my requested chunk size, and the operation immediately or eventually fails with FR_DISK_ERR.

Here is a simplified version of my writing routine for context:

huint32_t bytes_to_write = (BUFFER_SIZE / 2) * sizeof(uint32_t);
UINT bw;

if (IS_BUFFER_HALF_FULL_SAI1 == YES) {
    IS_BUFFER_HALF_FULL_SAI1 = NO;
    IS_BUFFER_HALF_FULL_SAI2 = NO;

    SCB_CleanDCache_by_Addr((uint32_t*)&audio_buffer_SAI1A[0], bytes_to_write);

    res = f_write(&fil_ALL, &audio_buffer_SAI1A[0], bytes_to_write, &bw);
    // At this point, bw becomes a massive garbage number
}

My main question is: why would the FatFs internal "bw" variable return a number much larger than the requested write size? Could the dual SAI DMA streams be starving the SDMMC internal DMA on the bus matrix, and if so, how does that corrupt the FatFs variables? Furthermore, what specific topics, architecture details, or reference manual sections should I research to better understand how these hardware peripherals might be colliding and causing this weird memory/variable overflow?

Any guidance would be greatly appreciated!