spi1 work well only in debug mode

[oshryatias]

Posted on January 22, 2014 at 09:41

i am trying to communicate between stm32100rb discovery value and transceiver cc2500 via spi1. for checking, i wrote a value to the cc2500 to specific register, and then, i read the value of this register, and print it.

when i use the debug, it work well, and give me the right value.(even when it in debug mode only, and i press the reset button, it also work well, although i don't running it with the debug application).when i download the same code, and running it without turn on the debug, it print me wrong value( like 'f' or '0', instead of '29' in my case)i will be happy for some advice.. thank you!

[chen]

Posted on January 22, 2014 at 16:57

Hi

''and running it without turn on the debug, it print me wrong value( like 'f' or '0', instead of '29' in my case) i will be happy for some advice..'' When you run it without the debugger - do you power the STM32 and cc2500 off the same source? Do you power the 2 up together?

[oshryatias]

Posted on January 22, 2014 at 17:12

hi, thank you!

the stm32 power by the usb cable and also by 5v pin by cp2102(ttl to usb) which i use for uart.the transceiver cc2500 power by connect to 3.3v pin (the cc2500 need to be power between 1.8-3.6v)

[Tesla DeLorean]

Posted on January 22, 2014 at 17:21

Would check how you're resetting the other device, and if you're waiting long enough at start-up for it to come ready/functional.

Review specs, add a delay

[oshryatias]

Posted on January 22, 2014 at 18:36

hello clive!

the cc2500 reset when it turn on.i already add a delay, i already ''play'' with this delay a lot.the cc2500 work with spi protocol. i wait after i turn the SS to low, before writing to the device.it work well with the debug(when i run all the code at once, not only step by step), what make the different? what the debug give me, which i need to use?

[Tesla DeLorean]

Posted on January 22, 2014 at 19:10

The debugger can enable pins, peripherals and clocks that you fail to do. The initial connection at reset takes a while to complete, allowing some code present to run first. Running code may also go slower, or have certain clocks/watchdogs disabled when wait for the user at the console.

Connect you device to a serial port, output diagnostic information there, have a Hard Fault handler that can catch/display fault information. Understand the flow and behaviour of your code off the debugger. Dump the register/peripheral settings in debug and non-debug modes and compare/contrast the differences.