Nucleo-L496ZG-P Issue flashing board

[cbarb2747]

For the first week of having the board, I was able to load different programs with no problem. Somehow, it seems that I got the board into a bad state.  Now, most of the times when I try to flash a program to the board I get the infamous:

Waiting for debugger connection...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Debugger connected

Waiting for debugger connection...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

Shutting down...

Exit.

Sometimes, I can get a program to flash if I, hit the reset button a bunch, unplug and plug back in the board, clean the workspace,

rebuild the workspace, then load the program. This is very annoying and frustrating when trying to

program and then debug a program. I have also tried different chords.
Any help would be greatly appreciated. I am not sure how this happened. Everything was run super smoothly at first with the board.

[Peter BENSCH]

Welcome @cbarb2747, to the community!

You have probably programmed something with an ultra-low power mode, so that the IDE can no longer access the target without the debugger option ‘Connect under Reset’.

Regards
/Peter

[cbarb2747]

Thank you for the warm welcome and the reply.  So I just need to go to the settings and check the debugger option 'Connect Under Reset'?  I am learning barre metal programming and manipulating the registers for my board and am writing some simple programs to work with uart and i2c.  It is weird cause I was programming some simple gpio programs with leds and push buttons last week and had no issue.  Is it just the programs I am writing now that are causing the low power mode or is there a way to get the board out of this state? 

[Peter BENSCH]

Well, there are several modes in which your STM32L496 can work, including the ultra-low power modes, in which access via SWD is only possible via hardware reset. If this has been set with the current programme, the STM32 will remain in this state until you programme it differently.

Nevertheless you can access the target by setting the following path (with STM32CubeIDE):

Run > Debug Configurations... > [make sure that your application on the left is selected] > tab Debugger > Reset behaviour: set Type = Connect under reset

Regards
/Peter

[cbarb2747]

Ok thanks so much.  Yeah not sure how the board would have gotten in this state. My programs are very simple. They are just empty stm projects and I import the header files to access the structs for the different registers.  And I am just doing bare metal programming with bit manipulations and accessing different registers for simple stuff like gpio, uart, i2c, etc.   I did not every specifically touch the swd pin programatically, but maybe I have to set the swd explicitely myself with the type of programming I am doing?  Maybe with a standard stm project the init for the Hal objects and stuff sets the swd pin to a specific state?   I'll try the above though and hopefully that solves my issue.  I'll keep you posted and mark the above as the accepted solution if it works out.  

Thanks,

Charlie

[cbarb2747]

I went to the above path and that option of 

Reset behaviour: set Type = Connect under reset

is already the set behavior. 

Thanks,

Charlie

[Peter BENSCH]

Bare metal programming is more for advanced users because too many things can be overlooked. But you can of course try to get to the root of the problem.

One tip would be to explicitly configure the SWD pins as SWD. However, access should still be possible with the ‘Connect under reset’ setting.

[cbarb2747]

Ok thanks.  Yeah I really want to develop my skills at it.  I've used some api's like the Hal objects from Texas Instruments and while they are good, I find myself trying to figure out how stuff works and beating my head against a wall cause I don't understand how some things work under the covers.  So I feel like deep diving into bare metal will help me have greater control and really dig deep into understanding what is going on.  I know it is very advanced and tricky.  I am a software engineer by trade in industry. I am trying to grow in a new direction and knowledge.  I have ben following a udemy hands on video course and it was going very smoothly, but then for some reason I ran into this issue.  Thank you for your help though and suggestions.  I'll keep plugging away and debugging. 

[cbarb2747]

I also tried to run the stmcube programmer and do an erase of the chip, but it won't stay connected.  Is this to the low power state?  And I looked at the path. you mentioned and it was already set to the state you mentioned when I was having the issuess

[cbarb2747]

I switched workspaces and tried to make a uart program.  I enabled a uart pin from the ioc file, it generated the code, and I tried to load it on the board.  And I had the same issue with Target not responding.  Not quite sure how my board got in this state.  I can sometimes get it to load a program onto the board after cleaning a bunch of times, unplugging it and plugging it back in etc.  This is really slowing down the process of developing.  I tried to use the stm programmer to erase the chip, but the board won't stay connected.  I also tried to go to the debug config and it seems the setting you told me to add is already set.   

This is very very strange.  I had been programming the board with no problems and then started having this issue.