view target-utils/libbase/waitarm.S @ 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 06ad5e30e8d0
children
line wrap: on
line source

/*
 * This assembly module provides a wait_ARM_cycles() function similar to
 * the one in TI's firmware; it is meant to gradually replace and phase out
 * osmo_delay_ms().  One loop count for this function equals 4 ARM clock
 * cycles when running out of IRAM; if the ARM clock is 52 MHz, 13 loop counts
 * equal one microsecond.
 *
 * Note the instruction sequence difference from TI's firmware version:
 * we use the SUBS instruction (equivalent of plain SUB in Thumb) and omit
 * the CMP, which is why our version is 4 cycles per loop (when running
 * out of IRAM), as opposed to 5 cycles per loop (plus wait states as they
 * execute from flash) in TI's fw version.
 */

	.text
	.code	32
	.globl	wait_ARM_cycles
wait_ARM_cycles:
	cmp	r0, #0
	bxeq	lr
1:	subs	r0, r0, #1
	bne	1b
	bx	lr