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.