ChibiOS Free Embedded RTOS

Posted: **Wed Jan 07, 2015 7:51 pm**

I've rolled my own board for a STM32F405 chip, and I am using the HSI oscillator as a clock source. I've started with a project that I developed on the F4 discovery board, and modified the mcuconf.h in the following way to adjust for the 16MHz internal oscillator:

Code: Select all

#define STM32_HSI_ENABLED TRUE
#define STM32_HSE_ENABLED FALSE
#define STM32_PLLSRC STM32_PLLSRC_HSI
#define STM32_PLLM_VALUE 16 // was 8

Which should provide the 168MHz system and 48MHz peripheral clocks.

The program I am working on runs, and I have confirmed the ADC is working correctly. However, when toggle output pins, they are not changing value. I have (maybe incorrectly) used the STM32F4_DISCOVERY board and STM32F4xx platform files. I have the specific output pins set to PAL_MODE_OUTPUT_PUSHPULL.

What might I have overlooked?

Posted: **Wed Jan 07, 2015 9:20 pm**

Probably the settings in boarh.h, all the differences are there.

Giovanni

Posted: **Thu Jan 08, 2015 2:01 pm**

Ok I think I am missing something fundamental. I am seeing the same behaviour on my F4 discovery so I don't think it is so much my homebrew board as much as my missing comething important in how GPIO is configured.

This software (since I had been using the F4 discovery) uses the four LED GPIOs to show me various states. It's nice because I can see it by eye, but also can hook my scope/logic analyzer up to the GPIOD12-15 pins to timings measure exactly as well.

My new board is a 64 pin F405 so it only has exposed ports A,B, and C. So basically I am trying to use alternate GPIO pins that are available to me.

In the past on my L1xx based projects, I've generally just set a pad to:

Code: Select all

palSetPadMode( XXXX, YY, PAL_MODE_OUTPUT_PUSHPULL );

and used it to toggle as an output.

Trying the same in my F4 project, say switching from using LED3 (GPIOD13) to say GPIOB13 I don't get the output toggling.

I've even tried setting the pin defaults to exactly the same as LED3 in board.h, that is I added the following to the appropriate bitmasks:

Code: Select all

PIN_OTYPE_PUSHPULL(GPIOB_PIN13)
PIN_OSPEED_100M(GPIOB_PIN13)
PIN_PUPDR_FLOATING(GPIOB_PIN13)
PIN_ODR_LOW(GPIOB_PIN13)
PIN_AFIO_AF(GPIOB_PIN13, 0)

I assume this makes the call to setPadMode( GPIOB, 12, PAL_MODE_OUTPUT_PUSHPULL ); redundant, but I left it in main all the same. Either way, GPIOB13 doesn't toggle, it simply sits at 0v.

Even more odd to me, if I switch again to using GPIOB2 instead, it does in fact toggle, but not with the same timing as the LED GPIOD13. Again, I've set the GPIOB2 pin up exactly the same way in board.h as GPIOD13.

What might I be doing wrong/misunderstanding?

thanks,
Dave

Posted: **Thu Jan 08, 2015 2:07 pm**

Note that wht you see in board.h are just the defaults, if you perform a palSetPadMode() after calling halInit() then the defaults are overridden.

Calling palSetPadMode() before halInit() does not work because clock paths are not initialized.

Giovanni

Posted: **Thu Jan 08, 2015 2:45 pm**

I am calling everything after halInit(), I've already learned that lesson the hard way

Posted: **Thu Jan 08, 2015 8:12 pm**

I've boiled the project down to the following code which still isn't working. I must be missing something completely silly. I started with the testhal/STM32F4xx/SPI demo's build system (and associated chconf.h, mcuconf.h and halconf.h).

I've used the board.h as edited previously (that is, I set the defaults for GPIOB11/12/13 to match those of the LED ports).

This is running on my STM32F4 discovery board, not my homebrew, so it shouldn't be an issue with my soldering at this point

Code: Select all

#include "ch.h"
#include "hal.h"

/*
 * Application entry point.
 */
int main(void) {

  /*
   * System initializations.
   * - HAL initialization, this also initializes the configured device drivers
   *   and performs the board-specific initializations.
   * - Kernel initialization, the main() function becomes a thread and the
   *   RTOS is active.
   */
  halInit();
  chSysInit();

  palSetPadMode(GPIOB, 11, PAL_MODE_OUTPUT_PUSHPULL );
  palSetPadMode(GPIOB, 12, PAL_MODE_OUTPUT_PUSHPULL );
  palSetPadMode(GPIOB, 13, PAL_MODE_OUTPUT_PUSHPULL );

  while( 1 ) {
    chThdSleepMilliseconds( 400 );
    palTogglePort(GPIOB, 11 );
    chThdSleepMilliseconds( 400 );
    palTogglePort(GPIOB, 12 );
    chThdSleepMilliseconds( 400 );
    palTogglePort(GPIOB, 13 );
  }

  return 0;

}

None of the GPIOs are toggling. Do they need to be loaded? I am just probing with my scope.

I have verified in the debugger that the code is running, and not just sitting in an exception handler or something (although with the simplicity of this example, that would be impressive

I'm at a complete loss.

Posted: **Thu Jan 08, 2015 8:21 pm**

Hi,

Your problem is here...

Code: Select all

   palTogglePort(GPIOB, 11 );

... but I will let you find it

Giovanni

Posted: **Thu Jan 08, 2015 8:49 pm**

AHhhhhhhhhhhhhhh!

I knew it had to be stupid. I probably cut and pasted from and example and didn't see the Pad->Port changeover.

That also explains the "weird timing" I was seeing previously, toggling the two "decimal" bit patterns were fighting each other.

Oh well, I guess you don't get smarter unless you are willing to admit you are an idiot sometimes and ask for help.

As always, I'm in your debt

d

ChibiOS Free Embedded RTOS

STM32F405 homebrew board

STM32F405 homebrew board

Re: STM32F405 homebrew board

Re: STM32F405 homebrew board

Re: STM32F405 homebrew board

Re: STM32F405 homebrew board

Re: STM32F405 homebrew board

Re: STM32F405 homebrew board

Re: STM32F405 homebrew board