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
-
you can't graph watched variables when using the emulated background JTAG refreshing [ Cortex A5D27 doesn't support high speed live watches according to ozone so is starting and stopping the MPU to read the values ]
they do happily slowly update which is fine given you only get 5Hz updating
but you can't graph the vatiables
-
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
-
why is there still no windows Dark theme option?
it's really horrible moving back from all the dark editors to a glaring white, in your face white windows.
i alwasy run with the windows Dark mode as well so you aren't even honouring the same thing as you do with Linux / OsX still
-
well just download it, find the instance of the structure and just change the U32 / memory fundamental value . that is all you need to show the issue as "Registers" is a global static variable with the union structs inside it
-
why does ozone not report when newer versions are available and support the really not difficult to implement auto updating ?
-
how do I know what boards you have ?
this elf file is for a samd20J17
it won't run on any hardware you have but you can find the "Registers" global object to find a bunch of examples of those structures
-
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
| +-- 00x1'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 -
sorry I read it as is it fixed in latest version as you normally put , but yes the point is its not fixed
-
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
-
why do the watches clear whe you open a new .elf / c.out etc?
that I think is more likely the way i am loosing them
-
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; -
am i missing something or is there no way for the list of watches to be remembered with the project file?
it's a PITA if you have a lot of watches setup and then you close the machine, ozone crashes or you restart it , re-open the project and all the watches are gone