<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="auto">Hi,<div dir="auto">Low power modes are indeed a difficulty when debugging.</div><div>Are you using the Kinetis low power mode PR? <a href="https://github.com/RIOT-OS/RIOT/pull/7897">https://github.com/RIOT-OS/RIOT/pull/7897</a></div><div>Do you have any feedback that could help getting it ready for merging?<br></div><div><br></div><div>I have had similar issues when experimenting with low power modes. Do you have access to the reset pin on your device?</div><div>If you have the reset pin connected on the JTAG header, you can use the OpenOCD option reset_config connect_assert_srst, in combination with the reset halt command to make the CPU halt so that you can reload a new firmware.</div><div><br></div><div>See <a href="https://github.com/RIOT-OS/RIOT/pull/7897/commits/a34d7ac3493e1b18d49c08eeada88725434e7b14">https://github.com/RIOT-OS/RIOT/pull/7897/commits/a34d7ac3493e1b18d49c08eeada88725434e7b14</a> for the config file change (part of #7897) and <a href="https://github.com/RIOT-OS/RIOT/pull/10479">https://github.com/RIOT-OS/RIOT/pull/10479</a> for using reset halt from the openocd.sh script.</div><div><br></div><div>Best regards,</div><div>Joakim<br></div><div dir="auto"><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">Den ons 19 dec. 2018 09:21 skrev Dylan Laduranty <<a href="mailto:dylanladuranty@gmail.com" target="_blank">dylanladuranty@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Olivier,</div><div>I had the same issue with openOCD and SAM0 MCU in the past. But I was always to recover my chips using JLinkExe tool from Segger. I just erased the whole memory using JLinkExe to unbrick the device and re-run openocd afterwards.You should probably take a look too.</div><div><br></div><div>Regards<br></div></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 19 déc. 2018 à 08:51, Olivier Fauchon <<a href="mailto:ofauchon2204@gmail.com" rel="noreferrer" target="_blank">ofauchon2204@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Bas, <div><br></div><div>I use NXP Kinetis KW2xd MCU and OpenOCD + JLink with SWD, for flashing. </div><div><br></div><div>I didn't know there were special procedures for unlocking devices. </div><div><br></div><div>I'll try to use NXP official IDE flash these chips again.<br></div><div><br></div><div>Thanks</div><div><br></div><div>Olivier</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 19 déc. 2018 à 08:17, Bas Stottelaar <<a href="mailto:basstottelaar@gmail.com" rel="noreferrer" target="_blank">basstottelaar@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Oliever,</div><div dir="ltr"><br></div><div>Which MCUs have you been playing with?</div><div><br></div><div>This is a common 'problem' that can occur when you indeed enable LPM (or other things like disable debug pins etc). Therefore, most MCUs have certain procedures to keep the MCU halted after a reset, before any code is executed and the MCU gets unreachable. IIRC, ARM Cortex provides a vector-catch operation to halt the MCU after reset. Some IDEs (like Simplicity Studio for EFM32 MCUs) have a special unlock operation. </div><div><br></div><div>Your solution isn't new, but works great to solve/work-around the problem ;-)</div><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail-m_-2345066448724154230m_9054372490487338134gmail-m_-5777290690681255627gmail-m_5210913401623384975gmail_signature"><div dir="ltr"><div><div>Kind regards</div><div><span style="font-size:12.8px">Bas Stottelaar</span><br></div><div><br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr">Op wo 19 dec. 2018 om 08:08 schreef Olivier Fauchon <<a href="mailto:ofauchon2204@gmail.com" rel="noreferrer" target="_blank">ofauchon2204@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr">Hi, </div><div dir="ltr"><br></div><div dir="ltr">I recently bricked a couple of MCUs playing with low power modes.</div><div dir="ltr">I'm still not sure what happened, but enabling LPM on my board makes JTAG </div><div>inoperant. </div><div><br></div><div>I spent a lot of time trying to save these dead MCUs.</div><div><br></div><div>To avoid this situation, I added some kind of recovery mode at boot : </div><div dir="ltr"><br></div><div dir="ltr"><br><div>board.c </div><div><br></div><div>void board_init(void) </div><div>...</div><div><br></div><div><div>    // Safeguard: Infinite loop if board started with buttons pushed</div><div>    gpio_init(BTN0_PIN, GPIO_IN_PU);<br></div><div>    gpio_init(BTN1_PIN, GPIO_IN_PU);</div><div>    if (!gpio_read(BTN0_PIN) ||  !gpio_read(BTN1_PIN) ) {</div><div>        gpio_set(LED0_PIN);</div><div>        gpio_set(LED1_PIN);</div><div>        while(1){}</div><div>    }</div></div><div><br></div><div>Did I reinvent the wheel ?</div><div>Do Riot have already mecanisms to delay boot , or other way to protect from bad images ? </div><div><br></div><div>Thanks</div><div>Olivier Fauchon</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@riot-os.org" rel="noreferrer" target="_blank">users@riot-os.org</a><br>
<a href="https://lists.riot-os.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.riot-os.org/mailman/listinfo/users</a><br>
</blockquote></div></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@riot-os.org" rel="noreferrer" target="_blank">users@riot-os.org</a><br>
<a href="https://lists.riot-os.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.riot-os.org/mailman/listinfo/users</a><br>
</blockquote></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@riot-os.org" rel="noreferrer" target="_blank">users@riot-os.org</a><br>
<a href="https://lists.riot-os.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.riot-os.org/mailman/listinfo/users</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_-2345066448724154230m_9054372490487338134gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>Dylan Laduranty<br></div></div></div></div></div></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@riot-os.org" rel="noreferrer" target="_blank">users@riot-os.org</a><br>
<a href="https://lists.riot-os.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.riot-os.org/mailman/listinfo/users</a><br>
</blockquote></div>