Not able to program STM32 MCU using JTAG interface
MCU : STM32L496
JFlash version: v6.32i
We are facing the "Connection to target under reset failed" issue, when we try to program the board with STM32 MCU.
We were programming the board before with no issues. This error started appearing suddenly and now we are not able to program the board. When we scoped the reset pin of the MCU, the reset pin is going low when we click the connect button in the JFlash and clearly the board is resetting (We can see the firmware functionality restarting).
We tried the following:
Tied the BOOT0 pin to VDD and tried booting to the system memory and then tried programming. But this doesn't made any difference.
Tried always pulling down the reset pin to GND while trying to flash.
We have ensured that there are no issues with the track leading to the JTAG interface of the MCU.
Could you please help to resolve this situation?
Is there any possibility that the firmware currently running in the MCU could prevent the flashing and lock the device?
embedded stm32 jtag
|
show 2 more comments
MCU : STM32L496
JFlash version: v6.32i
We are facing the "Connection to target under reset failed" issue, when we try to program the board with STM32 MCU.
We were programming the board before with no issues. This error started appearing suddenly and now we are not able to program the board. When we scoped the reset pin of the MCU, the reset pin is going low when we click the connect button in the JFlash and clearly the board is resetting (We can see the firmware functionality restarting).
We tried the following:
Tied the BOOT0 pin to VDD and tried booting to the system memory and then tried programming. But this doesn't made any difference.
Tried always pulling down the reset pin to GND while trying to flash.
We have ensured that there are no issues with the track leading to the JTAG interface of the MCU.
Could you please help to resolve this situation?
Is there any possibility that the firmware currently running in the MCU could prevent the flashing and lock the device?
embedded stm32 jtag
Have you checked with another board/controller if the connections works?
– A.R.C.
Nov 14 '18 at 12:09
Yes we have two more prototype boards. We checked flashing both boards. One of the board also moved into non flash-able state (i.e., this actually led us to doubts of our application firmware blocking the program flashing). However, the third board is working fine.
– HariP
Nov 14 '18 at 12:27
Hi HariP. What is the low power mode used by your firmware?
– Hugo Bevilacqua
Nov 14 '18 at 13:05
Now we are not making use of any low power modes in the firmware. We are running FreeRTOS task scheduler.
– HariP
Nov 14 '18 at 13:34
1
Successful JTAG connection is independent of being able to program the flash. The J-Flash output text may contain useful information - you should copy & paste that to your question. For example it indicates the power supply voltage which is critical. Is it possible you have enabled read-out protection? In your J-Flash installation folder you will find a command line tool JLinkSTM32.exe; I have had parts locked in ways that the J-Flash software could not connect to but which could be recovered using this tool. It will blank your device.
– Clifford
Nov 14 '18 at 19:39
|
show 2 more comments
MCU : STM32L496
JFlash version: v6.32i
We are facing the "Connection to target under reset failed" issue, when we try to program the board with STM32 MCU.
We were programming the board before with no issues. This error started appearing suddenly and now we are not able to program the board. When we scoped the reset pin of the MCU, the reset pin is going low when we click the connect button in the JFlash and clearly the board is resetting (We can see the firmware functionality restarting).
We tried the following:
Tied the BOOT0 pin to VDD and tried booting to the system memory and then tried programming. But this doesn't made any difference.
Tried always pulling down the reset pin to GND while trying to flash.
We have ensured that there are no issues with the track leading to the JTAG interface of the MCU.
Could you please help to resolve this situation?
Is there any possibility that the firmware currently running in the MCU could prevent the flashing and lock the device?
embedded stm32 jtag
MCU : STM32L496
JFlash version: v6.32i
We are facing the "Connection to target under reset failed" issue, when we try to program the board with STM32 MCU.
We were programming the board before with no issues. This error started appearing suddenly and now we are not able to program the board. When we scoped the reset pin of the MCU, the reset pin is going low when we click the connect button in the JFlash and clearly the board is resetting (We can see the firmware functionality restarting).
We tried the following:
Tied the BOOT0 pin to VDD and tried booting to the system memory and then tried programming. But this doesn't made any difference.
Tried always pulling down the reset pin to GND while trying to flash.
We have ensured that there are no issues with the track leading to the JTAG interface of the MCU.
Could you please help to resolve this situation?
Is there any possibility that the firmware currently running in the MCU could prevent the flashing and lock the device?
embedded stm32 jtag
embedded stm32 jtag
edited Nov 15 '18 at 7:17
HariP
asked Nov 14 '18 at 7:11
HariPHariP
365
365
Have you checked with another board/controller if the connections works?
– A.R.C.
Nov 14 '18 at 12:09
Yes we have two more prototype boards. We checked flashing both boards. One of the board also moved into non flash-able state (i.e., this actually led us to doubts of our application firmware blocking the program flashing). However, the third board is working fine.
– HariP
Nov 14 '18 at 12:27
Hi HariP. What is the low power mode used by your firmware?
– Hugo Bevilacqua
Nov 14 '18 at 13:05
Now we are not making use of any low power modes in the firmware. We are running FreeRTOS task scheduler.
– HariP
Nov 14 '18 at 13:34
1
Successful JTAG connection is independent of being able to program the flash. The J-Flash output text may contain useful information - you should copy & paste that to your question. For example it indicates the power supply voltage which is critical. Is it possible you have enabled read-out protection? In your J-Flash installation folder you will find a command line tool JLinkSTM32.exe; I have had parts locked in ways that the J-Flash software could not connect to but which could be recovered using this tool. It will blank your device.
– Clifford
Nov 14 '18 at 19:39
|
show 2 more comments
Have you checked with another board/controller if the connections works?
– A.R.C.
Nov 14 '18 at 12:09
Yes we have two more prototype boards. We checked flashing both boards. One of the board also moved into non flash-able state (i.e., this actually led us to doubts of our application firmware blocking the program flashing). However, the third board is working fine.
– HariP
Nov 14 '18 at 12:27
Hi HariP. What is the low power mode used by your firmware?
– Hugo Bevilacqua
Nov 14 '18 at 13:05
Now we are not making use of any low power modes in the firmware. We are running FreeRTOS task scheduler.
– HariP
Nov 14 '18 at 13:34
1
Successful JTAG connection is independent of being able to program the flash. The J-Flash output text may contain useful information - you should copy & paste that to your question. For example it indicates the power supply voltage which is critical. Is it possible you have enabled read-out protection? In your J-Flash installation folder you will find a command line tool JLinkSTM32.exe; I have had parts locked in ways that the J-Flash software could not connect to but which could be recovered using this tool. It will blank your device.
– Clifford
Nov 14 '18 at 19:39
Have you checked with another board/controller if the connections works?
– A.R.C.
Nov 14 '18 at 12:09
Have you checked with another board/controller if the connections works?
– A.R.C.
Nov 14 '18 at 12:09
Yes we have two more prototype boards. We checked flashing both boards. One of the board also moved into non flash-able state (i.e., this actually led us to doubts of our application firmware blocking the program flashing). However, the third board is working fine.
– HariP
Nov 14 '18 at 12:27
Yes we have two more prototype boards. We checked flashing both boards. One of the board also moved into non flash-able state (i.e., this actually led us to doubts of our application firmware blocking the program flashing). However, the third board is working fine.
– HariP
Nov 14 '18 at 12:27
Hi HariP. What is the low power mode used by your firmware?
– Hugo Bevilacqua
Nov 14 '18 at 13:05
Hi HariP. What is the low power mode used by your firmware?
– Hugo Bevilacqua
Nov 14 '18 at 13:05
Now we are not making use of any low power modes in the firmware. We are running FreeRTOS task scheduler.
– HariP
Nov 14 '18 at 13:34
Now we are not making use of any low power modes in the firmware. We are running FreeRTOS task scheduler.
– HariP
Nov 14 '18 at 13:34
1
1
Successful JTAG connection is independent of being able to program the flash. The J-Flash output text may contain useful information - you should copy & paste that to your question. For example it indicates the power supply voltage which is critical. Is it possible you have enabled read-out protection? In your J-Flash installation folder you will find a command line tool JLinkSTM32.exe; I have had parts locked in ways that the J-Flash software could not connect to but which could be recovered using this tool. It will blank your device.
– Clifford
Nov 14 '18 at 19:39
Successful JTAG connection is independent of being able to program the flash. The J-Flash output text may contain useful information - you should copy & paste that to your question. For example it indicates the power supply voltage which is critical. Is it possible you have enabled read-out protection? In your J-Flash installation folder you will find a command line tool JLinkSTM32.exe; I have had parts locked in ways that the J-Flash software could not connect to but which could be recovered using this tool. It will blank your device.
– Clifford
Nov 14 '18 at 19:39
|
show 2 more comments
2 Answers
2
active
oldest
votes
STM32L4 has a feature called Read-out Protection (RDP). See section 1.1 of AN4758. If your firmware application sets (intentionally or accidentally) the RDP level to 1 or 2 in the "option bytes" memory area then the SWD/JTAG port is disabled from accessing flash memory (read, write, and erase).
If the RDP is level 0 or 1 then you should be able to read the option byte memory area. If RDP is level 1 then you should be able to set it back to level 0. The flash memory will be erased when setting RDP back to level 0 but the SWD/JTAG port will get re-enabled. If the RDP level is 2 then I believe there is no way to reset it.
1
Even with read-out protection enabled it should be possible to connect the JTAG/SWD - you have to be able to get a connection to disable RDP. Ideally the question should include the J-Flash diagnostic log text to see at which point it is failing.
– Clifford
Nov 14 '18 at 19:43
@Clifford In our case we are not able to connect to the board. I have attached the image in the question.
– HariP
Nov 15 '18 at 7:19
add a comment |
This is a common problem with STM32 SWD interface. For successful programming you should not power your custom board/ other hardware with the ST link power, instead you should make the GND connection common and supply from external source. And if you are using ST link only for programming and not for debugging then you should use the STM32 bootloader(easier).
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53294840%2fnot-able-to-program-stm32-mcu-using-jtag-interface%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
STM32L4 has a feature called Read-out Protection (RDP). See section 1.1 of AN4758. If your firmware application sets (intentionally or accidentally) the RDP level to 1 or 2 in the "option bytes" memory area then the SWD/JTAG port is disabled from accessing flash memory (read, write, and erase).
If the RDP is level 0 or 1 then you should be able to read the option byte memory area. If RDP is level 1 then you should be able to set it back to level 0. The flash memory will be erased when setting RDP back to level 0 but the SWD/JTAG port will get re-enabled. If the RDP level is 2 then I believe there is no way to reset it.
1
Even with read-out protection enabled it should be possible to connect the JTAG/SWD - you have to be able to get a connection to disable RDP. Ideally the question should include the J-Flash diagnostic log text to see at which point it is failing.
– Clifford
Nov 14 '18 at 19:43
@Clifford In our case we are not able to connect to the board. I have attached the image in the question.
– HariP
Nov 15 '18 at 7:19
add a comment |
STM32L4 has a feature called Read-out Protection (RDP). See section 1.1 of AN4758. If your firmware application sets (intentionally or accidentally) the RDP level to 1 or 2 in the "option bytes" memory area then the SWD/JTAG port is disabled from accessing flash memory (read, write, and erase).
If the RDP is level 0 or 1 then you should be able to read the option byte memory area. If RDP is level 1 then you should be able to set it back to level 0. The flash memory will be erased when setting RDP back to level 0 but the SWD/JTAG port will get re-enabled. If the RDP level is 2 then I believe there is no way to reset it.
1
Even with read-out protection enabled it should be possible to connect the JTAG/SWD - you have to be able to get a connection to disable RDP. Ideally the question should include the J-Flash diagnostic log text to see at which point it is failing.
– Clifford
Nov 14 '18 at 19:43
@Clifford In our case we are not able to connect to the board. I have attached the image in the question.
– HariP
Nov 15 '18 at 7:19
add a comment |
STM32L4 has a feature called Read-out Protection (RDP). See section 1.1 of AN4758. If your firmware application sets (intentionally or accidentally) the RDP level to 1 or 2 in the "option bytes" memory area then the SWD/JTAG port is disabled from accessing flash memory (read, write, and erase).
If the RDP is level 0 or 1 then you should be able to read the option byte memory area. If RDP is level 1 then you should be able to set it back to level 0. The flash memory will be erased when setting RDP back to level 0 but the SWD/JTAG port will get re-enabled. If the RDP level is 2 then I believe there is no way to reset it.
STM32L4 has a feature called Read-out Protection (RDP). See section 1.1 of AN4758. If your firmware application sets (intentionally or accidentally) the RDP level to 1 or 2 in the "option bytes" memory area then the SWD/JTAG port is disabled from accessing flash memory (read, write, and erase).
If the RDP is level 0 or 1 then you should be able to read the option byte memory area. If RDP is level 1 then you should be able to set it back to level 0. The flash memory will be erased when setting RDP back to level 0 but the SWD/JTAG port will get re-enabled. If the RDP level is 2 then I believe there is no way to reset it.
answered Nov 14 '18 at 14:54
kkrambokkrambo
4,7391818
4,7391818
1
Even with read-out protection enabled it should be possible to connect the JTAG/SWD - you have to be able to get a connection to disable RDP. Ideally the question should include the J-Flash diagnostic log text to see at which point it is failing.
– Clifford
Nov 14 '18 at 19:43
@Clifford In our case we are not able to connect to the board. I have attached the image in the question.
– HariP
Nov 15 '18 at 7:19
add a comment |
1
Even with read-out protection enabled it should be possible to connect the JTAG/SWD - you have to be able to get a connection to disable RDP. Ideally the question should include the J-Flash diagnostic log text to see at which point it is failing.
– Clifford
Nov 14 '18 at 19:43
@Clifford In our case we are not able to connect to the board. I have attached the image in the question.
– HariP
Nov 15 '18 at 7:19
1
1
Even with read-out protection enabled it should be possible to connect the JTAG/SWD - you have to be able to get a connection to disable RDP. Ideally the question should include the J-Flash diagnostic log text to see at which point it is failing.
– Clifford
Nov 14 '18 at 19:43
Even with read-out protection enabled it should be possible to connect the JTAG/SWD - you have to be able to get a connection to disable RDP. Ideally the question should include the J-Flash diagnostic log text to see at which point it is failing.
– Clifford
Nov 14 '18 at 19:43
@Clifford In our case we are not able to connect to the board. I have attached the image in the question.
– HariP
Nov 15 '18 at 7:19
@Clifford In our case we are not able to connect to the board. I have attached the image in the question.
– HariP
Nov 15 '18 at 7:19
add a comment |
This is a common problem with STM32 SWD interface. For successful programming you should not power your custom board/ other hardware with the ST link power, instead you should make the GND connection common and supply from external source. And if you are using ST link only for programming and not for debugging then you should use the STM32 bootloader(easier).
add a comment |
This is a common problem with STM32 SWD interface. For successful programming you should not power your custom board/ other hardware with the ST link power, instead you should make the GND connection common and supply from external source. And if you are using ST link only for programming and not for debugging then you should use the STM32 bootloader(easier).
add a comment |
This is a common problem with STM32 SWD interface. For successful programming you should not power your custom board/ other hardware with the ST link power, instead you should make the GND connection common and supply from external source. And if you are using ST link only for programming and not for debugging then you should use the STM32 bootloader(easier).
This is a common problem with STM32 SWD interface. For successful programming you should not power your custom board/ other hardware with the ST link power, instead you should make the GND connection common and supply from external source. And if you are using ST link only for programming and not for debugging then you should use the STM32 bootloader(easier).
answered Nov 26 '18 at 9:47
MrAlphaMrAlpha
4619
4619
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53294840%2fnot-able-to-program-stm32-mcu-using-jtag-interface%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Have you checked with another board/controller if the connections works?
– A.R.C.
Nov 14 '18 at 12:09
Yes we have two more prototype boards. We checked flashing both boards. One of the board also moved into non flash-able state (i.e., this actually led us to doubts of our application firmware blocking the program flashing). However, the third board is working fine.
– HariP
Nov 14 '18 at 12:27
Hi HariP. What is the low power mode used by your firmware?
– Hugo Bevilacqua
Nov 14 '18 at 13:05
Now we are not making use of any low power modes in the firmware. We are running FreeRTOS task scheduler.
– HariP
Nov 14 '18 at 13:34
1
Successful JTAG connection is independent of being able to program the flash. The J-Flash output text may contain useful information - you should copy & paste that to your question. For example it indicates the power supply voltage which is critical. Is it possible you have enabled read-out protection? In your J-Flash installation folder you will find a command line tool JLinkSTM32.exe; I have had parts locked in ways that the J-Flash software could not connect to but which could be recovered using this tool. It will blank your device.
– Clifford
Nov 14 '18 at 19:39