comparison target-utils/libbase/abbdrv.c @ 497:74610c4f10f7

target-utils: added 10 ms delay at the end of abb_power_off() The deosmification of the ABB access code (replacement of osmo_delay_ms() bogus delays with correctly-timed ones, which are significantly shorter) had one annoying side effect: when executing the poweroff command from any of the programs, one last '=' prompt character was being sent (and received by the x86 host) as the Calypso board powers off. With delays being shorter now, the abb_power_off() function was returning and the standalone program's main loop was printing its prompt before the Iota chip fully executed the switch-off sequence! I thought about inserting an endless tight loop at the end of the abb_power_off() function, but the implemented solution of a 10 ms delay is a little nicer IMO because if the DEVOFF operation doesn't happen for some reason in a manual hacking scenario, there won't be an artificial blocker in the form of a tight loop keeping us from further poking around.
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 25 May 2019 20:44:05 +0000
parents 3d73d4d3527f
children 44a1de4264d8
comparison
equal deleted inserted replaced
496:3d73d4d3527f 497:74610c4f10f7
100 abb_power_off() 100 abb_power_off()
101 { 101 {
102 abb_init(); 102 abb_init();
103 serial_flush(); 103 serial_flush();
104 abb_reg_write(VRPCDEV, 0x01); 104 abb_reg_write(VRPCDEV, 0x01);
105 /*
106 * TWL3025 datasheet seems to indicate that the time for the DEVOFF
107 * command to take effect is 5 cycles of the 32.768 kHz clock.
108 * We'll do an ARM-timed delay of 10 ms before returning from
109 * this function.
110 */
111 wait_ARM_cycles(13000 * 10);
105 } 112 }