Waiting for debug commands

With no apparent reason, at some point my application stopped working.
Visual Studio seems to deploy, then it seems that the application never executes. Of course it did until a few minutes before and I don’t remember of any change
I’m using 2.2.2.1000 version of both libs and firmware. SITCore SCM20260E.
Of course, I tried erasing all and updating the firmware.
I with with and without external heap set.
I tried with a new app with a single debug line. Same.
I tried deleting the .vs folders.
TinyCLR Config can communicate and do everything with the device, so the device is not “dead” and communicates.
But, out of the blue, no way of runnings apps on it.
Any suggestion is welcome.

image

Try adding this before the debug.write

    while (!Debugger.IsAttached)
    {
        Thread.Sleep(1000);
    }

It will cause the process to wait until the debugger has been attached before proceeding.

1 Like

Nothing. The app doesn’t start at all, like the app was disabled by pin.

I add a detail that might not be a detail.
The first time I checked, after the app stopped working, the “disable app pin” was checked, in device configuration. Of course, I erased all and updated the firmware. Never seen that pin checked again, but the app still deploys and doesn’t start.
image

Hum… can you confirm that the device is using power? Are you able to write a program to flash an led?

I think the board runs correctly.

Problem here is, the board execute “debug.writeline(…)” quickly and done.
Debug.writeline take a while (flush) data before user see it. At this time the board is done (quit).

Try add sleep (-1), you will see the output, I hope.

There was a breakpoint. So I guessed it should have stopped anyway, and it does when the app is executing. Anyway, I just fixed and will write about in a next reply.

Found the solution and it was my bad. Sorry for having disturbed you, @Dat_Tran and @Mr_John_Smith, and thanks for your time.
The problem was a change in the hardware. The new version of the custom board that I had had NOT the app pin jumped. When I had a problem (a different problem) with the debugger, I erased and updated the firmware in the attempt to solve, but by doing that I missed flagging the “disable app pin”, which was not necessary in the previous custom board because of the hardware jumper.
So, I shoot in my feet and the app could not run anymore…
Setting the “disable app pin” solved. Sorry and thanks again.

3 Likes