3 of 3 people found this helpful
Hi! Sorry you ran into a problem.
Short answer to your question: No, you cannot debug with Miniprog3 in ModusToolbox. A longer/background answer below. But first...
What I'd like to know is "where did you look for the answer?" Even if you did not actually look, where would you expect to find it? We may have a gap in where/how we tell people what probes are supported. If so, I'd like to fill that gap.
The answer is on our programming tools web page, here: https://www.cypress.com/products/psoc-programming-solutions Both probes are listed, along with the supported IDEs.
OK, now for the background.
MiniProg4 has KitProg3 firmware inside. That's what ModusToolbox requires. KitProg3 and KitProg2 firmware are 100% hardware compatible. So you can upgrade the onboard firmware on an older kit to KitProg3, no problem. Life good.
MiniProg3 has the equivalent of KitProg2 firmware, but it is not in fact KitProg2. Same functionality, completely different implementation under the hood. It is not hardware compatible with KitProg3, so you can't upgrade. It is what it is. And it does not work with ModusToolbox.
The underlying transport mechanisms are completely different. MiniProg3 uses a Cypress-proprietary connection protocol. ModusToolbox uses industry standard CMSIS-DAP and OpenOCD. MiniProg4 (really the KitProg3 firmware installed on the MiniProg4) supports that, and MiniProg3 does not.
Thanks in advance, sorry if I spouted too much, and apologies that you went down a dead end.
Thank you Jim,
As per your question on the documentation, I think a guide in the Modus homepage would have helped, like in the Quick Start Guide or the User Guide. But the best place where I'd like the information to be would be in Modus itself.
I was able to debug with my Miniprog4 by selecting the Kitprog3 debug configuration just to try, as I didn't see Miniprog listed as a debug configuration. I wasn't even sure it would work. If the Miniprog4 could be listed as such (Miniprog4 instead of Kitprog3), and the Miniprog3 would do a pop-up ("Miniprog3 not supported, refer to xxxxxx.pdf"), then it'd be great.
But an entry in the User Guide and Quick Start Guide would be sufficient.
Appreciate the feedback. I'll add that onto the tech writing task list - adding this info in one of those guides. That should be easily doable.
I'm going to go explore in the IDE. The kits come with on board firmware, KitProg3. MiniProg 4 has the same firmware. But you typically would not know that. So.... of course you have a very reasonable question, how do I connect using an MP4? I have to ponder how I might solve that problem. If I relabel tthe launch configurations as MiniProg4, the people using the onboard programmer end up in the position you're in now. But I may be able to finagle something. Like you, I believe the best place for this info is "at the point of use" and not in a manual.
I appreciate your investigation, Jim.
If you don't mind, as you seem involved in the development of Modus Toolbox, I have another suggestion, although it's not related to this current thread.
In this other thread: Modus 2.0 tries to compile files that are excluded , I make a suggestion about where to document the CY_IGNORE variable of the Makefile. I took me a while to find how to properly exclude files from the build. Maybe put the documentation in the User Guide instead of the Building from CLI guide? Or if the "exclude from build" option of Eclipse could be used as-is, that would also be great. Although I kind of like the approach of using the Makefile instead of the IDE, if it's clear that the IDE option doesn't work.
Hey Fred! I'm just a lowly apps engineer. But I know the team, and I know how to open tickets. I do have some insight. And yes, this is a topic that needs explaining. I'll reply in the original thread as well, because folks may find this in either place now.
Although I kind of like the approach of using the Makefile instead of the IDE, it's clear that the IDE option doesn't work.
Indeed. The root cause of this is simple: the ModusToolbox build infrastructure replaces the build system inherent in Eclipse. So, when you try to manipulate details of the build in the IDE (like "don't compile these files") that has precisely ZERO impact on the actual build. This is not obvious or intuitive. As you learned, you must modify the makefile, NOT the IDE, to build correctly.
To deal with this general problem, in some cases the engineers actually removed common settings panels from the IDE, so you can't use the IDE to modify compiler settings. I am going to assume it is not possible to disable this bit of functionality (mark files to NOT compile) in the IDE. Hence you went down the obvious (and wrong) path.
We need to document that. 100% agree. I may be doing that documenting. Thanks for calling my attention to this topic.