- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Original question:
LAUNCHXL-F280049C: ADCC results1 register != PPB2|3 values unmapped .cio
Hello,
The Instaspin FAST estimator 25µs ISR calls (below get ROM filtered speed) is delayed until closed loop target 350Hz is reached second time only. Seemingly after adding SCIB ISR handler INT9.4 giving INT 1.3 global priority with Alert errata fix B2B clear ACK's need asm(" NOP"). Adding NOP shown in advisory locks SCIB ISR loop (giving ADCC1 global priority) after it clear ACK's group 1 (INT1.3) and prior to EINT SCIB INT9.4. Let me be very clear, SCIB INT9.4 gives seamless and global priority to (ADCC1 INT1.3) without any visible interruptions to or from SCIB ISR 9.4 (5-20ms) vector.
3 Silicon Revision B Usage Notes and Advisories:
//Good interrupt nesting code
PieCtrlRegs.PIEACK.all = 0xFFFF;
Below estimator call moved into Instaspin mainISR (25µs) return response to get ROM filtered speed is no better than being called from while loop (main.c) with global update calls to ROM.
Motor first run time speeds 0Hz-350Hz without returns of any speed updates from ROM in open loop. Motor stops 0Hz sound changes rotor goes to target (350Hz) during second time sounds like closed loop again 0Hz-350Hz. The sudden and dramatic stop hold torque at 0Hz and rotor second jumps 0Hz-350Hz is very bad for hardware.
When target speed (350Hz) first time seems (open loop), rotor rapidly stops 0Hz and 2nd time rapidly accelerates to 350Hz (closed loop). Both times after update to (motorVars.speed_Hz) CCS debug or disconnected XDS110. So disconnected LCD start button sends SCIB INT9.3 command to start motor via (motorVars.flagRunIdentAndOnLine = true) and it goes to 0Hz-350Hz, trajectory speed set via GUI page loading where slider widget can increase or decrease rotor speed after reaching preloaded trajectory speed.
The main_ISR() loop (located RAM LS4-5) where ROM calls for speed updates (without SCIB being enabled) are slightly delayed recalling open loop only during slow speed observer <1Hz in CCS debug.
Q1: What is a work around to stop below ROM call from being delayed in main_ISR() or in main() labs.h call to global update via while loop?
Q2: Do we need to use RAM loaded FAST library calls, no longer calls to ROM embedded estimator (to slow) and what about difficulty level to test isLab07 (SPEED_MODE) this way?
Example ROM calls issue added to mainISR():
motorVars.speed_Hz = EST_getFm_lp_Hz(estHandle);
Or adding below still has slow update.
motorVars.speed_krpm = (motorVars.speed_Hz * (60 / 1000.0 /
USER_MOTOR_NUM_POLE_PAIRS));
Hello Yanming.
So it doesn't need to be copied to RAM as the codes in flash.
Yet flash memory is slower than RAM memory fast library and ROM should be slower than RAM access times. The flash library application is loaded into .est.data RAMLS4-7. Flash fast library constants remain in flash memory section .econst.
Yet the decimation time mainISR() remains 25µs via 6 ticks. RAM loaded library should return (motorVars.speed_Hz) value without same delay of ROM estimator returns. The (motorVars.speed_Hz) remains blank (delayed return) even without CCS debug runtime.
There is a missing Boolean switch in the FAST flash library and will not load (user.h) motor parameters without flag motorID=1. Adding motor ID bool flag below and compiler throws an exception. Fails even after adding #includes "userPRAMS.h" to isLab07 or placing (userParams.flagMotorIdentified = true) main.c. The module includes should point to motorID added bool switch.
The difficulty level is about 6 to import the fast library load it into RAM. However trying to include ESMO (esmo.c) cause many compiler errors. So project compiles without error excluding ESMO but still fails to load motor parameters in CCS debug even with SCIB disabled in project.
