Same code and different behaviour for several boards

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello to everyone,

 

I have just joined a new project and one part is about controlling motors with xmega128D3 chip.

 

A button with three status is linked to the chip to PF7, PR0 and PR1.

PF7 : button is pushed down, it allows to select which motor to control. There are indeed two motors.

PR0 : button is pushed left, selected motor is running clockwise. The speed is managed by how far we push the button to the left.

PR1 : button is pushed right, same as above with counterclockwise.

 

I am a bit lost because the button operates correctly on 3 boards and not correctly on 3 others. Boards come from the same production lot.

If I push the button in order to select the motor it doesn't respond to the push. I am not available to select the motor.

 

I suspect that I am not flashing the boards the same way despite the fact that I make the same steps. I have even read the flash memory and EEPROM from working boards to retrieve the binaries and flash them to not working boards. But it doesn't work.

What could generate a different behaviour from the same code ?

 

I have checked fuses and they are identical.

 

I have notice that the production signatures are different between the boards. According to the datasheet it's a factory configuration and cannot be changed . Could it be the root cause ? Do I need to modify the code according to the production signature ?

 

I have really no clue about the root cause. Any suggestion would be appreciated.

It's quite hard to validate the PCB because it's very small and I can obviously broke the CPU with bad manipulation.

 

I have extracted the part of the code about PF7 for everyone that would like to have a look. It's quite a huge project so I hope that it's enough.

int main(void)
{
    // Configure clock to 32MHz http://forkineye.com/configure-avr-xmega-32mhz/
    OSC.CTRL |= OSC_RC32MEN_bm | OSC_RC32KEN_bm;  /* Enable the internal 32MHz & 32KHz oscillators */
    while(!(OSC.STATUS & OSC_RC32KRDY_bm));       /* Wait for 32Khz oscillator to stabilize */
    while(!(OSC.STATUS & OSC_RC32MRDY_bm));       /* Wait for 32MHz oscillator to stabilize */
    DFLLRC32M.CTRL = DFLL_ENABLE_bm ;             /* Enable DFLL - defaults to calibrate against internal 32Khz clock */
    CCP = CCP_IOREG_gc;                           /* Disable register security for clock update */
    CLK.CTRL = CLK_SCLKSEL_RC32M_gc;              /* Switch to 32MHz clock */
    OSC.CTRL &= ~OSC_RC2MEN_bm;                   /* Disable 2Mhz oscillator */

    // Port Init PORTF
    PORT_SetPinsAsOutput( &PORTF, 0b01110000 );
    /* Configure PC7 as input, triggered on falling edge. */
    PORT_ConfigurePins( &PORTF,0b10000000,false,false,PORT_OPC_PULLUP_gc,PORT_ISC_FALLING_gc );
    PORT_SetPinsAsInput( &PORTF, 0b10001111 );
    Reactu_Entree();
    /* Configure Interrupt0 to have medium interrupt level, triggered by pin 0,1,2,3. */
    PORT_ConfigureInterrupt0( &PORTF, PORT_INT0LVL_MED_gc, 0b00001111 );

    // Port Init PORTR
    PORT_ConfigurePins(  &PORTR, 0b00000011,false,false,PORT_OPC_PULLUP_gc,PORT_ISC_FALLING_gc );
    PORT_SetPinsAsInput( &PORTR, 0b00000011 );

    // Timer init it every 1ms
    TCD0_CTRLA = TC_CLKSEL_DIV1_gc;
    TCD0_CTRLB = 0;
    TCD0_CTRLC = 0;
    TCD0_PER = TCD0_PERIODE;  //2040;
    TCD0_INTCTRLA = TC_OVFINTLVL_MED_gc;

    while(1)
    {
        // blabla
    }
}

ISR(TCD0_OVF_vect)
{
    if ((PORTF_IN & BM_7)==0)  // Here is the problem : condition not met if button is pushed
    {
	Bouton_Push=TRUE;
        Led_CPU_HS_OFF;
    }
    else
    {
        Bouton_Push=FALSE;
    }
}

 

I am starting a new project under Atmel Studio in order to only detect the button pushes. I want to simplify code to it's minimum and see what's going on.

 

Thank you for any help

 

This topic has a solution.
Last Edited: Wed. May 20, 2020 - 07:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

xaam wrote:
I have just joined a new project ... I am a bit lost 

Can't you get the existing people on the project to get you started?

 

I suspect that I am not flashing the boards the same way 

Surely, the existing team members are best placed to help you with that?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

xaam wrote:

I am a bit lost because the button operates correctly on 3 boards and not correctly on 3 others. Boards come from the same production lot.

If I push the button in order to select the motor it doesn't respond to the push. I am not available to select the motor.

So a 50% failure rate, this sounds like a h/w issue not a s/w issue if flashed with the same code and fuse settings.

xaam wrote:

I suspect that I am not flashing the boards the same way despite the fact that I make the same steps. I have even read the flash memory and EEPROM from working boards to retrieve the binaries and flash them to not working boards. But it doesn't work.

What could generate a different behaviour from the same code ?

Again this could be a h/w problem, examine each board under a magnifying glass and look for shorted pins, open traces, and misplaced parts!  Once this is ruled out, then begin s/w trouble shooting!

 

xaam wrote:
I have notice that the production signatures are different between the boards. According to the datasheet it's a factory configuration and cannot be changed . Could it be the root cause ? Do I need to modify the code according to the production signature ?

That's NOT good, either you have a wiring issue with your connections to the micros with your programmer/debugger, clocks are not running or are running at the wrong speed, or the chips are not the same (do the markings look identical to the ones that do work?, were they obtained from the same source, from a reputable source????)    Identical chips have the same signature!

xaam wrote:
It's quite hard to validate the PCB because it's very small

Proper test fixtures are required for any size board!  PCB should have test points for manufacturing test and operation verification testing.

 

Hope that helps, are you allowed to post pictures of your unit?

 

Jim

 

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

xaam wrote:
Boards come from the same production lot.

That doesn't preclude that the switches are fitted / soldered incorrectly.

 

<edit> or even that the switches have different part numbers </edit>

Last Edited: Fri. May 15, 2020 - 06:53 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello everyone,

 

 

I have indeed confirm that it's a hardware issue.

 

Thank you for your help, your answers gave me some ideas.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for feedback - please mark the solution

 

see Tip #5 in my signature, below: 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...