# CORTEX-M LPCOPEN USB-VCOM basics - proper way to build a simple FSM

I'm working on a project involving the LPC4370 mcu (LPC link 2 eval board) and Matlab. I need my embedded code to be user-reconfigurable from matlab: the user sends a command, the mcu replies.

I'm using LPCOpen VCOM example as base: it uses USB w/ interrupt.

My C code:

static uint8_t g_rxBuff[256];
[...]
while (1)
{
/* Sleep until next IRQ happens */
__WFI();

/* Read cmd */
rdCnt = vcom_bread(&g_rxBuff, 1);
state = g_rxBuff[0];

if(rdCnt == 1)
{
switch (state)
{
case 'a':
/* cmd ackn */
vcom_write((uint8_t*)&g_rxBuff, 1);

case 'b':
/* cmd ackn */
vcom_write((uint8_t*)&g_rxBuff, 1);

case 'c':
/* cmd ackn */
vcom_write((uint8_t*)&g_rxBuff, 1);
}
}
}


Here I wait for a command and then I try to echo it back to host (i.e. ackn).

In Matlab

BaudRate=115200;
serial_object=0;
delete(instrfind('Type','serial'));
serialInfo = instrhwinfo('serial');
serial_object=serial('/dev  /ttyACM1','BaudRate',BaudRate,'InputBufferSize',4*4096,'OutputBufferSize',4*4096);
fopen(serial_object);

sendCmd(serial_object,'a');
sendCmd(serial_object,'b');
sendCmd(serial_object,'c');


Where

function ret = sendCmd(serial_object, cmd_sent)
fwrite(serial_object, cmd_sent, 'char');
disp(strcat('SENT:  ', cmd_sent));
else
disp(strcat('ERROR:  ', cmd_sent));
end
end


So this basically never works. I always get errors like:

Warning: The specified amount of data was not returned within the Timeout period.'serial' unable to read any data. For more information on possible reasons, see Serial Read Warnings.

Since I've been working on this for a while now I can tell that port set-up is ok, I managed to get data out of the mcu with the same configuration.

So I think I'm missing some how-to-basics here. The only assumption I made is that the USB IRQ is triggered everytime Matlab writes to the mcu.

EDIT: Some more infos from the debugger. Here's IRQ calls after 1 matlab fwrite:

• Using breakpoint debugging will probably break USB connectivity the first time you hit a breakpoint. And hardcoding the ttyACM address is dubious, as it will likely increment any time the USB re-enumerates if anything still has the "old" port open. First thing to do is to try sending the commands from a terminal program, if that doesn't work look at your embedded code. If that does work, consider giving your matlab code reasonable wait for an answer behavior. May 7 '19 at 13:10
• @ChrisStratton thanks for the reply. I know that hardcoding ACM is not handy.. better way of doing this? I tried with cuteCOM: i sent chars 'a', 'b' and 'c' and again I see IRQ activity from the debbuger, but not the desired behavior. No response from MCU, no breakpoint hit. May 7 '19 at 13:26
• Again, trying to use the debugger should be assumed to break USB connectivity. You'll need to find another way to determine what is going on. Typically it's best to start with serial UART logging if you doubt the USB code. May 7 '19 at 13:28
• So you would suggest running the target only? Completely unplugging the debug probe? May 7 '19 at 13:50
• If you don't know your tool suite well enough to know a more specific way to control if the debugger is interacting, then yes, unplug it. May 7 '19 at 13:54