jfrenzel

That did the trick - thank you!

I am having trouble configuring the protocol tool to "spy" on an SPI bus. I have a custom design in the PL portion of a Zynq that acts like a SPI master to output three bytes and produces the correct waveforms shown in the "logic.jpg" picture. However, when I try to capture the same transaction using the Protocol tool, I get extra bytes of 0h00 after every "real" byte. (protocol.jpg). Any thoughts?

We are running a lab full of Cerebot MX7ck, but have a cabinet full of the original MX7 boards. Is there a summary or migration sheet available that discusses the differences between the ck and the original?

We have a lab full of Cerebot MX7 boards, some older than others, and this week two of them went belly up, with the programmer no longer able to read the Device ID. Both MPLAB IDE and IPE can connect to the debugger, but not the chip itself. So no programming and no erasing. (see attached screenshot) First guess of course is ESD, but allegedly one board failed when the student was not connecting leads - simply downloading and running code. This makes me wonder if there is something in the programming circuitry that may have failed, rather than the PIC32 itself. Does anyone have any suggestions on an *easy* way to verify whether the appropriate signals are being generated to place the PIC32 into programming mode (or whether there are known failure mechanisms for these boards)? Sadly, the PIC32 is backordered 52 weeks, so even if I wanted to try and replace the chip that isn't an option. Thank you, A (currently) Rather Unhappy User

Deleting all of the user AppData for mplab_ide solved the problem.

All of the sudden, MPLAB IDE on my office PC doesn't "see" the licensed debugger on my Cerebot board, but I can easily program the PIC32 from the IPE, so I suspect it is some sort of software problem. I am using MPLAB IDE 3.65 - old, I know - but it works great in our labs, as does the Cerebot board, so it is something with my office computer. I've tried reinstalling MPLAB, rebooting, etc., with no success. I did happen to notice that the licensed debugger on my Cerebot board is using an older version of the firmware than the Cerebot boards in the lab, but that didn't prevent me from programming my Cerebot board from my laptop or from one of the lab computers. Any thoughts? My guess is "cached" Windows "app" data, or some Windows update. Jim

I would think this would be obvious, but the documentation doesn't go into much detail. We develop MPLAB projects for the PIC32 under FreeRTOS using the xc32-gcc compiler. All of our projects follow a specific directory structure and use relative paths, so I would like to exclude the FreeRTOS header and source files when packaging the project, but obviously not when building the project. My question is how best to do this. I believe that the reference design that I used as a starting point created logical folders for the FreeRTOS source and then added specific files as existing sources, because they get included in the zip archive and also appear under "General" category of the "Project Properties" dialog box, as well as the "File Inclusion/Exclusion" category. I suspect what I need to do is remove these logical folders from the project and then modify the gcc command line to specify the necessary include directories. Does that sound correct? Thanks!

I get the impression that you can do a HW/SW co-design project on the Zybo Z7 by entering the hardware design using Vivado and then exporting to Vitis for the software, similar to the pre-2019 flow. (Please let me know if that is incorrect!) Can you do the same with the original Digilent Zybo? (We have a lab full of the original boards.) Thanks! Jim