Path: ...!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!cleanfeed2-b.proxad.net!nnrp2-1.free.fr!not-for-mail
Newsgroups: fr.sci.electronique
From: JKB <JKB@hilbert.invalid>
Subject: Mise en veille =?UTF-8?Q?m=C3=A9moire?= MRAM
Reply-To: <jkb@invalid>
User-Agent: slrn/1.0.3 (Linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Date: 26 Apr 2023 08:01:03 GMT
Lines: 91
Message-ID: <6448da3f$0$3072$426a34cc@news.free.fr>
Organization: Guest of ProXad - France
NNTP-Posting-Date: 26 Apr 2023 10:01:03 CEST
NNTP-Posting-Host: 62.212.98.88
X-Trace: 1682496063 news-4.free.fr 3072 62.212.98.88:11246
X-Complaints-To: abuse@proxad.net
Bytes: 3900

	Bonjour à tous,

	Je poste ici (j'ai aussi contacté le support du fabricant, sans
	réponse pour l'instant).

	Dans un circuit, j'utilise une mémoire MR25H256A. Il s'agit d'une
	mémoire magnétique permettant l'horodatage d'événements. J'arrive
	sans problème à y écrire et à relire les données, le problème n'est
	pas là. Le problème tourne autour du mode SLEEP. Je ne sais pas si
	certains d'entre vous ont déjà utilisé ce genre de mémoire.

	Actuellement, j'initialise la mémoire au démarrage du firmware et
	je lui envoie une commande sleep. Ensuite, le circuit se met en
	veille profonde (CPU arrêté, redémarrant sur une interruption d'une
	horloge à temps réel). La première interruption arrive pour
	l'instant au bout d'une minute, mais en utilisation réelle, ce sera
	plutôt une semaine. Entre le démarrage et le traitement de la
	première interruption, la mémoire n'est pas en veille (ça se voit à
	sa consommation). Lors du reveil du CPU, je lui envoie une seconde
	commande et, miracle, le composant se met effectivement en veille !
	J'ai essayé de truander en envoyant deux fois la commande SLEEP lors
	de l'initialisation, en introduisant un délai entre les deux
	commandes SLEEP, ça ne fonctionne pas et je ne comprends pas.

	Le code actuel est le suivant :

void
mram_init()
{
    uint8_t     sr;

    // wp à l'état bas : impossible d'écrire dans le registre de statut
    gpio_off(&gpios[gpio_wp_mram]);

    mutex_lock(&mutex_spi);
    spi_select_device(dev_mram);
    gpio_on(&gpios[gpio_hold_mram]);
    spi_select_device(dev_none);
    mutex_unlock(&mutex_spi);

    mram_command0(MRAM_WAKE);

    sr = 0x82;
    mram_command0(MRAM_WREN);
    gpio_on(&gpios[gpio_wp_mram]);
    mram_command1(MRAM_WRSR, &sr);
    gpio_off(&gpios[gpio_wp_mram]);
    mram_command0(MRAM_WRDI);

    mram_command0(MRAM_SLEEP);
    return;
}

// MRAM_WREN, MRAM_WRDI, MRAM_SLEEP, MRAM_WAKE
void
mram_command0(uint8_t commande)
{
    mutex_lock(&mutex_spi);
    spi_select_device(dev_mram);
    spi_send8(commande);
    spi_select_device(dev_none);
    mutex_unlock(&mutex_spi);
    return;
}

	Après l'interruption, j'envoie simplement à la mémoire :

	mram_command0(MRAM_SLEEP);

	Comme la commande est traité la seconde fois, je suppose que la
	routine mram_command0() fonctionne.

	mutex_lock/unlock sont là parce que le firmware est multitâche et
	temps réel. spi_select_device() sélectionne le bon composant sur le
	bus SPI (il y a un capteur de température, un écran epaper, une RTC,
	un modem...). Ce bus SPI fonctionne bien. gpio_on/off positionnent
	les différentes lignes de contrôle de la mémoire.

	J'ai essayé tout ce qui était rationnel, j'ai relu la doc, je ne
	vois pas pourquoi après un 'certain' temps, la commande SLEEP est
	traitée et pourquoi elle ne l'est pas la première fois.

	Je suis preneur de toute idée.

	Bien cordialement,

	JKB

-- 
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.