C2000 Control Blockset does not work

Hello everyone,

I have an issue when using the C2000 control blockset for TI F28379D launchpad. As you can see, after "build,deploy&start", there was nothing in the output (zero voltage). I did set the constant 1 (boolean type), as you can see in the images. Hope that someone could help me. Much appreciated. I am using 2023a

Answer 1

[Umar]

Hi @BTV,

I took a close look at your three screenshots and I don't think there's anything wrong with your block setup at all. Your Constant block is configured correctly (value 1, boolean output), and your GPIO Digital Output block is also set up right — GPIO19 checked, "Toggle GPIO19" left unchecked, so it's in regular mode like it should be. Your build log also shows a clean, successful build and deploy, so the toolchain isn't the problem either.

The real issue is the specific pin you picked: GPIO19. On the F28379D LaunchPad, that pin doubles as the SCI‑B receive line (SCIRXDB) — it's literally documented that way in TI's own board pinout guide for this LaunchPad. So even though your Simulink model configures it correctly as a plain digital output, the board's hardware wiring/pin muxing means it doesn't behave as a clean GPIO output. I also found an older TI/MathWorks support case where another user hit this exact same problem on this exact board — GPIO19 came out stuck instead of toggling the way it was commanded, and MathWorks confirmed it was a UART pin conflict and told them to just avoid that pin. On top of that, I found a separate TI E2E thread (unrelated to Simulink, just plain C firmware) where someone independently ran into GPIO19 failing to work correctly specifically on this LaunchPad, while the same code worked fine on other boards with different pin numbers for SCI‑B. So this isn't a one-off fluke.

Bottom line: it's not a blockset bug, it's a pin choice issue. Try switching your Digital Output to a different pin in that same GPIO16~GPIO23 group — GPIO20, GPIO21, GPIO22, or GPIO23 should all be safe bets since they're not shared with UART. Rebuild, deploy, and check the voltage again. I'd expect it to work right away once you're off GPIO19.

Let me know how it goes after you swap the pin.

[BTV]

@Umar Hi Umar, thank you for your response. Actually, I had the same issue with several other GPIO pins before trying GPIO19, I just selected GPIO19 randomly to demonstrate the problem in the screenshots. I also tried some of the GPIO pins you suggested, but the issue remained the same. There was still no voltage at the output. I have tested this with three different F28379D LaunchPads and one F28069M LaunchPad, and unfortunately, none of them produced a GPIO output after building and deploying the model. So, it seems that the issue may not be specific to GPIO19.

[Umar]

Hi @BTV,

Thanks for testing across all those boards — that tells us it's not a pin problem, so ignore my earlier GPIO19 suggestion.

Here is what I'd try next, based on MathWorks' own documentation rather than guessing:

Run their official test example first. MathWorks has a ready-made example just for checking this. For the F28069M, it blinks the onboard LED using GPIO pin 39 (blue) or 34 (red), with Toggle GPIO turned on and the Constant block's sample time set to 0.5 seconds. For the F28379D, it uses GPIO pin 34 for the red LED on CPU1. Build one of these exact examples on one of your boards. If the LED doesn't blink either, that tells us the problem is happening before your program even starts running properly, and it has nothing to do with GPIO block settings.

Check the "Boot from Flash" setting. This is in Configuration Parameters → Hardware Implementation → Hardware board, right next to where you choose the board. MathWorks' docs say if this isn't enabled, your application loads into RAM instead of flash. Worth checking this is set the way you expect on all your boards.

For the F28379D, check the CPU selection. It's a dual-core chip, so your model has to be tied to a specific CPU (CPU1 or CPU2). MathWorks warns that if you use the same GPIO pins on both CPUs, or your model isn't matched to the CPU that's actually set to boot, nothing will show up on the pin even if the build succeeds.

Try the LED blink example first since it's the fastest way to tell if this is a deployment problem or a GPIO-specific one. Let me know what happens and we can go from there.