Posts by AndyR

    VAR_ALLOW_BMA_EMULATION is on and has been - hence i said I have seen and understood the massive difference in update rates for this mode of operation being limited to 5Hz but sample rate is no issue for this

    this is what happens when i try and use this

    "tick" is added as a watch, set to refresh at 1Hz and it does indeed update in the watch window at 1Hz

    when then try to graph "tick" then you just spit out a bunch of error messages in the console

    which contradicts what the manual / you say

    given you can refresh watched data at up to a few Hz in the background on MPUs that don't support the full high speed sampling mechanism over JTAG, why does the Timeline / data sampling?

    using J-Trace with Cortex A5D27 which doesn't support the full high speed background refresh

    this appears in the console


    Hardware setup does not support data sampling.
    Current setup does not support background memory access mode
    Error (84): Failed to start high speed sampling (HSS).

    i don't see why the mechanism for flushing the data from the processor should matter to being able to graph / do stats on a variable ( which does appear in the data sampling window but obviously doesn't update ) given that as the user we know and understand the sampling restrictions of the hardware platform

    it's compiled under IAR


    this is a dump out of that union + another one using the iar ielfdumper tool


    0x1'a743: | + union_type (82)
    | | sibling 0x1'a7d1
    | | name UnControlReg
    | | byte_size 0x4
    0x1'a756: | | member (86)
    | | type 0x1'a76c
    | | accessibility public
    | | data_member_location [plus_uconst 0]
    0x1'a75f: | | member (49)
    | | type 0x1'a9a5
    | | accessibility public
    | | name u32
    | | data_member_location [plus_uconst 0]
    0x1'a76c: | | + structure_type (87)
    | | | sibling 0x1'a7d0
    | | | byte_size 0x4
    0x1'a772: | | | member (88)
    | | | type 0x1'a9a5
    | | | accessibility public
    | | | name OpenLoop
    | | | data_bit_offset 0x0
    | | | bit_size 1
    0x1'a783: | | | member (88)
    | | | type 0x1'a9a5
    | | | accessibility public
    | | | name SaveCal
    | | | data_bit_offset 0x1
    | | | bit_size 1
    0x1'a793: | | | member (88)
    | | | type 0x1'a9a5
    | | | accessibility public
    | | | name LoadCal
    | | | data_bit_offset 0x2
    | | | bit_size 1
    0x1'a7a3: | | | member (92)
    | | | type 0x1'a9a5
    | | | accessibility public
    | | | data_bit_offset 0x3
    | | | bit_size 1
    0x1'a7ab: | | | member (88)
    | | | type 0x1'a9a5
    | | | accessibility public
    | | | name EraseCal1
    | | | data_bit_offset 0x4
    | | | bit_size 8
    0x1'a7bd: | | | member (88)
    | | | type 0x1'a9a5
    | | | accessibility public
    | | | name EraseCal2
    | | | data_bit_offset 0xc
    | | | bit_size 8
    | | +-- 0
    | +-- 0

    0x1'1ebd: | + union_type (64)
    | | sibling 0x1'2012
    | | name UnStatusReg
    | | byte_size 0x4
    0x1'1ecf: | | member (70)
    | | type 0x1'1ee5
    | | accessibility public
    | | data_member_location [plus_uconst 0]
    0x1'1ed8: | | member (39)
    | | type 0x1'2204
    | | accessibility public
    | | name u32
    | | data_member_location [plus_uconst 0]
    0x1'1ee5: | | + structure_type (65)
    | | | sibling 0x1'2011
    | | | byte_size 0x4
    0x1'1eeb: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name ADCUpdated
    | | | data_bit_offset 0x0
    | | | bit_size 1
    0x1'1efe: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name TestMode
    | | | data_bit_offset 0x1
    | | | bit_size 1
    0x1'1f0f: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name CalDataValid
    | | | data_bit_offset 0x2
    | | | bit_size 1
    0x1'1f24: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name StartingUp
    | | | data_bit_offset 0x3
    | | | bit_size 1
    0x1'1f37: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name DoingStartUpChecks
    | | | data_bit_offset 0x4
    | | | bit_size 1
    0x1'1f52: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name BadPressureSensor
    | | | data_bit_offset 0x5
    | | | bit_size 1
    0x1'1f6c: | | | member (67)
    | | | type 0x1'2204
    | | | accessibility public
    | | | data_bit_offset 0x6
    | | | bit_size 2
    0x1'1f74: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name EepromFound
    | | | data_bit_offset 0x8
    | | | bit_size 1
    0x1'1f88: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name EepromOk
    | | | data_bit_offset 0x9
    | | | bit_size 1
    0x1'1f99: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name DriverFound
    | | | data_bit_offset 0xa
    | | | bit_size 1
    0x1'1fad: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name DriverOk
    | | | data_bit_offset 0xb
    | | | bit_size 1
    0x1'1fbe: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name AmbPressFound
    | | | data_bit_offset 0xc
    | | | bit_size 1
    0x1'1fd4: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name AmbPressOk
    | | | data_bit_offset 0xd
    | | | bit_size 1
    0x1'1fe7: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name OutPressFound
    | | | data_bit_offset 0xe
    | | | bit_size 1
    0x1'1ffd: | | | member (66)
    | | | type 0x1'2204
    | | | accessibility public
    | | | name OutPressOk
    | | | data_bit_offset 0xf
    | | | bit_size 1
    | | +-- 0
    | +-- 0

    it answers the question , however it doesn't mean it is an entirely sensible philosophy

    its not uncommon to have different elf files for the same project that you would want to switch between without the rest of the environment changing as it is still the same "thing" just different version of code

    given it takes a split second to delete watches and significantly longer to add them back in I would much rather you didnt try and be clever and guess what the user is trying to do by changing the object file as you will invariably guess wrong.

    even if it is a system preference to not destroy the user environment if the data file changes that would be something

    no

    typedef union
    {
    struct
    {
    uint32_t SldEn : 1;
    uint32_t TecEn : 1;
    uint32_t IntegrationCap : 1;
    uint32_t : 1;
    uint32_t SaveCal : 1;
    uint32_t LoadCal : 1;
    uint32_t LoadCalToSystem: 1;
    uint32_t RebootFpga : 1;

    uint32_t StopAnMux : 8;
    uint32_t EraseFgpaFirmware1 : 8;
    uint32_t EraseFgpaFirmware2 : 8;
    };
    uint32_t U32;
    } UnControlReg;

    you can see in the picture the bottom 2 bits are set in the U32 but you dont display any of the struct values

    union with struct overlaying with U32 & array of 2 U16
    U32 & 2 U16s show ok
    struct doesn't but all show as the same address [ as you would expect ]

    typedef union
    {
    struct
    {
    uint32_t PowerEnable : 1;
    uint32_t Startup : 1;
    uint32_t Fault : 1;
    uint32_t HwFault : 1;

    uint32_t Present : 1;
    uint32_t xExpanderPresent : 1;
    uint32_t xExpanderOk: 1;
    uint32_t : 1;
    uint32_t xChargerPresent : 1;
    uint32_t xChargerOk : 1;
    uint32_t SmartBattPresent : 1;
    uint32_t SmartBattOk : 1;
    uint32_t : 4;

    uint32_t HwFaultShadow : 1;
    uint32_t Updated : 1;
    uint32_t Channel : 1;
    } ;
    uint32_t u32;
    uint16_t aU16[2];
    } UnBatteryStatusReg;