AMC-BLDC - set option bytes

[davidetome]

Task description

Check the possibility of setting the option bytes automatically at the end of the test.

Definition of Done

• [ ] feature added and tested

cc @valegagge @marcoaccame @maggia80

[marcoaccame]

Hi @davidetome, the embot::hw::bsp::specialize() of the amcbldc calls a verification of the FLASH banks that uses a reading of the option bytes with HAL_FLASHEx_OBGetConfig().

I believe that there is a function also to set them.

[davidetome]

Hi @davidetome, the embot::hw::bsp::specialize() of the amcbldc calls a verification of the FLASH banks that uses a reading of the option bytes with HAL_FLASHEx_OBGetConfig().

I believe that there is a function also to set them.

Thank you very much @marcoaccame !! I will take into account this as soon as I will work on it! 👍🏼

[davidetome]

I found some references also here to do this using HAL API :

• https://community.st.com/t5/stm32-mcus/how-to-program-stm32-option-bytes-with-the-hal-api/ta-p/49660

I added a function in the test FW to test it, but I'm facing issues w/ the debugger (flash timeout)

@marcoaccame / @fgarini are these the correct option bytes to be set?

cc @valegagge @MSECode

[fgarini]

Resolved

Ciao @davidetome a suggestion may be to check if any additional precaution is needed for the H7 compared to the example you follow. Here's the specific reference manual for the H7: https://www.st.com/resource/en/reference_manual/rm0399-stm32h745755-and-stm32h747757-advanced-armbased-32bit-mcus-stmicroelectronics.pdf In particular the section for the option bytes management is the 4.4

[edit] Seen marcoaccame's comment, put the comment on spoiler since I misunderstood and the original topic was referring to a different microcontroller

[marcoaccame]

ciao @davidetome, the above picture does not seem to me of the amcbldc but rather of a dual core stm32h7xx of the amc / amcfoc board.

for the amcblcd the option bit we need for sure is the one that configures FLASH as a single bank. I don't know the name of the option bit on cubeprogrammer, only the name in the code that checks it:

void verify_flash_bank()
{
    FLASH_OBProgramInitTypeDef odb = {0};   
    HAL_FLASHEx_OBGetConfig(&odb);

    uint8_t detectedbanks = ((odb.USERConfig & FLASH_OPTR_DBANK) == FLASH_OPTR_DBANK) ? 2 : 1;

[fgarini]

this should be unchecked for having a single bank as for the indication above

We also use to put the BOR_LEV to 4

[marcoaccame]

I found some references also here to do this using HAL API :

• https://community.st.com/t5/stm32-mcus/how-to-program-stm32-option-bytes-with-the-hal-api/ta-p/49660

this is interesting. just an idea for the future: to improve the above code so that it checks the dual back option bit and if not what is wanted it corrects it.

[davidetome]

ciao @davidetome, the above picture does not seem to me of the amcbldc but rather of a dual core stm32h7xx of the amc / amcfoc board.

ciao @marcoaccame , it's my fault I uploaded the incorrect screenshot...tomorrow I'll check 👍🏼

[davidetome]

I added a function in the test FW to set needed option bytes :

• https://github.com/davidetome/icub-firmware/commit/e43e16dc697f3e9c57f1a94120a9ec42765abe5d

    HAL_StatusTypeDef testOB(){
            uint8_t data[8] {0};        
            uint8_t res {0};
            data[0] = 0xAA;

            FLASH_OBProgramInitTypeDef OB;

            HAL_FLASH_Unlock();
          HAL_FLASH_OB_Unlock();

            OB.OptionType = OPTIONBYTE_USER;
          OB.USERType = OB_USER_DBANK | OB_USER_BOR_LEV;
            OB.USERConfig = OB_DBANK_128_BITS | OB_BOR_LEVEL_4;

            if ( HAL_FLASHEx_OBProgram(&OB) != HAL_OK )
          {
              HAL_FLASH_OB_Lock();
              HAL_FLASH_Lock();
                data[0] = 0xBB;
                sendCan(data);
              return HAL_ERROR;
          }

            sendCan(data);

          HAL_FLASH_OB_Lock();
          HAL_FLASH_Lock();
            return HAL_OK;
        }

And the relative CAN command (0x0E) to be sent to execute and test it :

    static void eventhread_onevent(embot::os::Thread *t, embot::os::EventMask eventmask, void *p)
    {
        if(0 == eventmask)
        {   // timeout ...     
            return;
        }

        // we clear the frames to be trasmitted
        outframes.clear();   
                std::uint8_t remaining = 0;
                if(true == embot::core::binary::mask::check(eventmask, evRXcanframe))
        {        
          embot::hw::can::Frame canframe;

                    embot::hw::can::get(embot::hw::CAN::one, canframe, remaining);

                    switch(canframe.data[0]){

                        //Test CAN
                    case 0x00 : embot::core::wait(300* embot::core::time1millisec); testCan(); break;

                        //Check test fw revision              
                        case 0x01 : embot::core::wait(300* embot::core::time1millisec); getFirmwareVersion(); break;

                        //Test LEDs off
                        case 0x02 : embot::core::wait(300* embot::core::time1millisec); testLeds(0); break;

                        //Test LEDs on
                        case 0x03 : embot::core::wait(300* embot::core::time1millisec); testLeds(1); break;

                        //Test micro DEV_ID
                        case 0x04 : embot::core::wait(300* embot::core::time1millisec); testIdCode(canframe); break;

                        //Test Vin
                        case 0x05 : embot::core::wait(300* embot::core::time1millisec); testVin(); break;

                        //Test Cin
                        case 0x06 : embot::core::wait(300* embot::core::time1millisec); testCin(); break;

                        //Test VAUXOK
                        case 0x07 : embot::core::wait(300* embot::core::time1millisec); testVauxOk(); break;

                        //Test VCCOK
                        case 0x08 : embot::core::wait(300* embot::core::time1millisec); testVccOk(); break;

                        //Test FAULT ON
                        case 0x09 : embot::core::wait(300* embot::core::time1millisec); testFault(1); break;

                    //Test FAULT OFF
                        case 0x0A : embot::core::wait(300* embot::core::time1millisec); testFault(0); break;

                        //Test I2C
                        case 0x0B : embot::core::wait(300* embot::core::time1millisec); testI2c(i2c); break;

                        //Test HALL
                        case 0x0C : embot::core::wait(300* embot::core::time1millisec); testHall(); break;

                        //Test ECODER
                        case 0x0D : embot::core::wait(300* embot::core::time1millisec); testEncoder(); break;

                        //Test Option Bytes
                        case 0x0E : embot::core::wait(300* embot::core::time1millisec); testOB(); break;

                        default : break;
                    }           
        }   
    }

Anyway, I didn't test it since I faced problems with the test FW which do not communicate on the CAN bus anymore.

It sounds very strange since I tested the FW on the temporary test jig as shown in the PI17 review demo.

cc @valegagge @MSECode @marcoaccame @fgarini @maggia80

[MSECode]

With @marcoaccame and @fgarini we actually check which option byte should be enabled and how to set them. However, the fw that tests it need to be re-checked. In the meanwhile I'll move back this issue to triage and when we are going to work on this I'll re-set it in progress.