2009-08-29 02:43 PM
J-Link error
2011-05-17 03:59 AM
I assume that the problem was caused by a ''bad'' program, that changed the STM configuration in a way that disrupted the JTAG communication (for example: changing the JTAG pins to GPIO configuration).
I did not added strange features, the program just did not operated normally. The second board got sick only after I worked with the bad program.2011-05-17 03:59 AM
Sorry to be a pest - suspect that others share (or will in future) my concern.
Assume that the ''bad'' program altered the JTAG pin/pins. I do ''not'' understand ''how'' then - changing the boot from flash to ram (so that you can load a new, ''correct'' program)- *** BY ITSELF *** restores the JTAG functionality. Believe that you use the JLink (JTAG debug probe) to load the STM32's ram with your new program - but HOW can this work if the JTAG pins are ''out'' of JTAG mode??? (I can see this working if you loaded the new program by Uart or any NON-JTAG method - was this what you did?)2011-05-17 03:59 AM
When booting from RAM, the ''bad'' code resides in Flash will not be executed. So you can connect to STM32 device. In this case you can use JFlash or program running from RAM to erase the flash or you can load a ''correct'' program into Flash(and not RAM)which will replace the bad one. After this you can boot from Flash.
2011-05-17 03:59 AM
Very well explained - thank you. You diagnosed the problem instantly and resolved it.
Now I offer a technique to ''recover JTAG'' - WITHOUT having to change the boot pins and having to load a ''safe'' new program. We use this method on all of our STM32 (and other ARM) designs - it has often ''saved'' us. Simply include small code which ''looks'' for some special event (switch closure, ADC level, etc.) BEFORE you change (either deliberately or inadvertently) switch JTAG pin/pins to GPIO. Place this code very early in your program - this allows an easy/graceful recovery should you lose JTAG... (in our case - we restore JTAG when ''special'' event occurs. During development - when JTAG use is heavy - we reverse the ''default.'') [ This message was edited by: jj.sprague on 20-01-2009 17:58 ]2011-05-17 03:59 AM
I've been hammered by this problem for a long time, now. It seems to happen to me after exiting a debug session inharmoniously, which is inevitable because even it the ''debug'' mode the STM32 doesn't seem to be haltable when it's in sleep mode.
Anyway, I'm pretty fed up and I hope that simply using a newer revision will fix this.2011-05-17 03:59 AM
I have been revisiting the STM32 hardware recently and I am still unable to use the JLink program to erase. I suspect this might be due to my having old STM32 chips or, more likely, a different board than the standard STM32 kit.
So I wrote this program to compile and load via IAR. Quick and dirty, but it works in place of JLink's ''erase chip''.Code:
void main ( void ) { u32 i; u32 start_addr; u32 end_addr; RCC_DeInit(); RCC_HCLKConfig(RCC_SYSCLK_Div1); RCC_PCLK2Config(RCC_HCLK_Div1); RCC_PCLK1Config(RCC_HCLK_Div1); RCC_ADCCLKConfig(RCC_PCLK2_Div6); RCC_AHBPeriphClockCmd( RCC_AHBPeriph_FLITF, ENABLE); RCC_APB1PeriphClockCmd( (RCC_APB1Periph_BKP | RCC_APB1Periph_PWR) , ENABLE); FLASH_SetLatency(FLASH_Latency_0); FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable); FLASH_HalfCycleAccessCmd(FLASH_HalfCycleAccess_Enable); /* FLASH_START_ADDR = 0x08000000 on as many STM32 models as I know * FLASH_PAGE_SIZE usually is 1024, check your device * FLASH_NUM_PAGES depends on your device */ start_addr = FLASH_START_ADDR; end_addr = FLASH_START_ADDR + (FLASH_PAGE_SIZE*FLASH_NUM_PAGES); FLASH_Unlock(); for (i=start_addr; i<end_addr; i+=FLASH_PAGE_SIZE) { FLASH_ErasePage(i); } while (1); }2011-05-17 03:59 AM
Hi,
Have you tried the lasted J-link software here : ? Cheers, STOne-32.