Friday, May 25th 2018, 1:08pm UTC+2

You are not logged in.

  • Login
  • Register

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,516

21

Thursday, August 14th 2008, 2:35pm

Hello gpontis,

can you please send us a stripped down version of the project you use,
which shows the problem?

I will send you an e-mail, too so you have my e-mail address to send to project to.

Best regards,

Alex

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,516

22

Tuesday, August 26th 2008, 1:14pm

Hello gpontis,

we do not see a problem here.
As soon as we get a sample project which shows the problem we can investigate this further.

Best regards,

Alex

blakec1

Beginner

Date of registration: Jan 10th 2009

Posts: 1

23

Saturday, January 10th 2009, 7:06am

Wrong AHB ID

I had a variation of the same problem. My error message was the same. I post the following to help those in the same shape.

I was setting up my FSMC memory controller bus to talk to an external LCD and set the latency of the flash to 0 instead of 1 (to see if it would speed up access to the LCD). Turned out this "wing it" idea would cost me 6 hours.

p.FSMC_DataSetupTime = 1; moved to xxxx = 0;

After executing this line of code and debugging - the JLINK refused to connect (IAR 5.2, Jlink driver 4.00a). Chip was the STM32F103E. I got a stream of obscure errors that did not point to the write problem (stack pointer errors, debug variable's out of range etc.). The only cure was the hold the Reset line low while telling IAR to debug. It magically fixed itself after I got the timing right. Before I tried this fix - I deinstalled the IAR, Segger programs and did a registry clean. Reinstalled after powering down all equipment for 10 minutes... None of this did anything but waste time.

After I fixed it with the reset - I changed the line of code again to see if it was repeatible. It was... Beware as this problem looks for all the world like the debugger is blown up, or the software environment is corrupt - neither of which is the real problem. You have likely just put the STM32 in a "non-communicative state" that even a hard powerdown won't (or might not) cure. You have to boot the debugger while resetting the chip.

I suspect the chip was trying to access its internal flash at an impossible speed and just wouldn't communicate until the hard reset fix. The problem below sounds like you could get the same problem if the chip will not come out of sleep without the hard reset. Good luck all...