Skip to main content
T
Thomas Laurenson
Visitor II
June 11, 2020
Solved

Test Bench using CubeMonitor, Flash the MCU

  • June 11, 2020
  • 2 replies
  • 1319 views

Hello,

After testing and messing a bit with CubeMonitor, I think that this could be an interesting tool to build test benches, in order to test boards after production, as you could monitor almost everything and trigger events (such as blinking a LED) by writing variables.

So my question: is it possible to actually flash the MCU with the elf file using CubeMonitor ?

Or would I have to somehow script the flash procedure using CubeProgrammer CLI then start CubeMonitor ? and this way I guess I will have to deal with Monitor & Programmer pre-empting the ST-LINK probe ?

Best,

Thomas

    This topic has been closed for replies.
    Best answer by stephane.legargeant

    Hello Thomas

    STM32CubeMonitor do not have feature to flash the MCU with the elf file. The elf is only used to find the symbol list and addresses.

    There should be some options to do the flashing.

    First, there is an "exec" node in node-RED to launch some commands. So you should be able to launch STM32CubeProgrammer CLI from a flow. For the access pre-emption, when the acquisition is not running, STM32CubeMonitor is not locking the probe. So you can make a sequence where acquisition is stopped, flashing is started (and programmer takes the control), and acquisition is restarted after some time. The probe will reported as disconnected by cubeMonitor during the flashing, but cubeMonitor will reconnect when flashing will be done. (after some seconds, the timeout is configured in setting file).

    An other option could be to user ST-Link "shared mode" or "tcp" in cube monitor. In this case CubeProgrammer and CubeMonitor can have shared access to the probe. It may be slower. I have tested STM32cubeIDE and STM32cubeMonitor in shared mode, and it is fine, the IDe is able to flash or download while CubeMonitor is connected.

    If you want to perform a complex test sequence, you can check the node "node-red-contrib-finite-statemachine" which is helpful to write a sequence.

    Best regards

    Stephane

    2 replies

    S
    stephane.legargeantAnswer
    ST Employee
    July 9, 2020

    Hello Thomas

    STM32CubeMonitor do not have feature to flash the MCU with the elf file. The elf is only used to find the symbol list and addresses.

    There should be some options to do the flashing.

    First, there is an "exec" node in node-RED to launch some commands. So you should be able to launch STM32CubeProgrammer CLI from a flow. For the access pre-emption, when the acquisition is not running, STM32CubeMonitor is not locking the probe. So you can make a sequence where acquisition is stopped, flashing is started (and programmer takes the control), and acquisition is restarted after some time. The probe will reported as disconnected by cubeMonitor during the flashing, but cubeMonitor will reconnect when flashing will be done. (after some seconds, the timeout is configured in setting file).

    An other option could be to user ST-Link "shared mode" or "tcp" in cube monitor. In this case CubeProgrammer and CubeMonitor can have shared access to the probe. It may be slower. I have tested STM32cubeIDE and STM32cubeMonitor in shared mode, and it is fine, the IDe is able to flash or download while CubeMonitor is connected.

    If you want to perform a complex test sequence, you can check the node "node-red-contrib-finite-statemachine" which is helpful to write a sequence.

    Best regards

    Stephane

    T
    Thomas LaurensonAuthor
    Visitor II
    August 26, 2020

    Hi Stephane,

    Sorry for the late response, I was in vacataion ;).

    Thanks a lot for the infos !

    I was able to succesfully flash the MCU using the "exec" node with CubeProgrammer CLI.

    I will try that state machine node.

    I was a total NodeRed newbie before CubeMonitor, and it's in fact a great tool to monitor values in real time where a break point would not be helpful.

    Great job here ST !

    Regards,

    Thomas.

    Terms & ConditionsAccessibility statement