2016-03-17 05:43 AM
Hi,
I am still debugging a bus fault for almost 4 months.I read about DISDEFWBUF flag from ACTLR, then, i check the register window. what I have there is ACR register which contains DISDEFWBUF bit.I tried to set that bit using register window input also, through hardcode by:long* plFlag = (long*)(0xE000E008
);plFlag = 0x02;how ever, it doesnt set.I would like to ask for help if anyone know how to set this? if it is possible?I read also that there is 3 revision of Cortex M3, the oldest one doesnt have the DISDEFWBUF. I am searching if STM32F103ZE happen to fall to the oldest revision of Cortex M3.Also, if someone can advice me if there is a tool which can help debugging easy.I read about the ETM, though im not yet familiar to this. Im currently using ST Link, EAWRM and NORTi for the OS,Regards,MJ #trace-pin-used #imprecise-hard-fault-stm32f103z2016-03-17 05:52 AM
I'm not sure if you have a copy-and-paste typo or a funny of the forum, but all you seem to be doing is changing the value of the pointer - not the intended memory-location that it was pointing to initially. Your compiler may have issued a warning.
The second line should read: *plFlag = 0x02;Including the initial ''*''.Hope this helps,Danish2016-03-17 05:21 PM
Hi,
Sorry it was indeed a typographical error, i forgot to put* in here. It is the value of the pointer that I set. Not really the address. I used *plFlag = 0x02;But still, DISDEFWBUF cannot change value.Someone can teach me if its possible for STM32F103ZE device?thanks,MJ2016-03-21 06:47 AM
According to ST Application Note AN3364, stm32f103 is Cortex-M3 r1p1
http://www.st.com/web/en/resource/technical/document/application_note/DM00024853.pdf - Danish2016-03-21 12:47 PM
Kind of thing you also expect to find in the specific part errata
''revision r1p1-01rel0 of the CortexM3core''Here the medium density onehttp://www.st.com/st-web-ui/static/active/en/resource/technical/document/errata_sheet/CD00190234.pdf
Four months!?! Isn't the write ''imprecise'' because it is displaced in time via the write buffers from the instruction?Do you have any consistency about where, and how, the fault is occurring?2016-03-23 05:36 AM
Hi Clive,
Actually the bus fault happen semi randomly. In different screens upon pressing key on touch screen. But its not consistent in a way that it always happen. For example I am in a screen where I can press a Key 1 to Key 10 and an OK Cancel. I just have to press key randomly and in 15 - 20 minutes it will freeze. (the freeze is ether imprecise bus fault or my cyclic handler or task will stop all of a sudden).I will check out the link you sent. thanks again.and by the way, I am also trying to workout on using J-Trace, but unfortunately,the product I am working on, the hardware is already fix. TRACE0-3 and TRACECK is being used as Address Bus<23-19> of external memory(ROM/RAM). Any idea if theres still workaround on this problem?Really, I appreciate your help.Thanks,MJ2016-03-23 05:49 AM
I just checked the eratta.
I learned fromhttp://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/Cihcbadd.htmlr1p1 doesnt support ACTLR register as well as DISDEFWBUF.My only hope is to use ETM.2016-03-23 05:55 AM
Typically people just disconnect the high order address pins, and lose some of the external memory.
If you can't create a failing scenario with less memory, then your options will fall back to adding in levels of diagnostic output, either via USART or SWV, so you can understand the flow, and pin the failure to specific subroutines or operations. If it is related to DMA or IRQ activity.