PIC18F, TCP/IP stack et bootloader???

[invite1a47bfa2]

Bonjour à tous,

J'ai développé une interface Ethernet utilisant un PIC18F87J60 et les outils TCP/IP de microchip (TCP/IP stack) !

A chaque mise à jour du programme du PIC je suis obligé de démonté la carte PIC du système afin de la reprogrammer...

J'aimerais faire évoluer le système en mettant en œuvre une programmation par Ethernet... (Une sorte de bootloader quoi..)

L'idée serait la suivante : si le système reçoit une trame Ethernet commençant par "#FAFAh" (par exemple), il exécute une fonction qui dans l'ordre :
1 - demande par Ethernet le nouveau code su PIC
2 - réceptionne et mémorise le nouveau soft
3 - reprogramme le PIC et le reset...

Jusqu'au 1, je sais faire, par contre je ne vois pas comment et ou mémoriser le code reçu et comment reprogrammer et reseter le PIC...

Est ce que vous avez une idée?
Est ce comme ca qu'il faut faire?

Merci pour votre aide,

Alex
-----

[RISC]

Salut,

Pourquoi n'utilises-tu pas le projet gratuit Internet Bootloader pour PIC18 qui est depuis 1 ou 2 ans dans la stack TCPIP Microchip.
Le projet s'appelle : TCPIP Internet Bootloader App

a+

[invite1a47bfa2]

En cherchant hier, j'ai vu qu'il existait effectivement ce bootloader, qui a mon avis va parfaitement faire l'affaire....

Actuellement, mon programme est construit sur le projet : TCPIP Demo App. Après compilation j'obtiens un fichier (toto.hex)

J'ai trouvé dans l'aide du TCPIP stack comment utiliser le bootloader !


Dans l'ordre ca donne:
1 - je compile le projet bootloader et programme mon PIC
2 - je construit une connection TFTP avec le module Ethernet et charge toto.hex via réseau

Une fois ceci exécuté est ce que le bootloader reste actif?

Je suppose que oui sinon l'intérêt serait quasi nul... Mais je voudrais en être certain...

Merci de votre aide !

Alex

[invite1a47bfa2]

J'arrive pas à le compiler pour le PIC18F87J60 ??

[A voir en vidéo sur Futura]

[RISC]

Salut,

Quelle version des librairies MAL utilises-tu ?

Je viens d'essayer de le compiler et cela passe nickel pour le 87J60.

Il suffit de faire 2 choses :
1/ tu changes le nom du PIC dans MPLAB : Configure > Select Device
2/ tu retires le fichier linker existant dans le projet MPLAB pour mettre à la place du fichier existant du 97J60, le fichier linker pour le 87J60 que tu trouves ici (dans les dernières librairies) :
c:\Microchip Solutions v2010-08-04\TCPIP Internet Bootloader App\Linker\18f87j60i_bootloade r.lkr

a+

[invite1a47bfa2]

J'ai changé le fichier du "linker" dans le projet et la compilation est ok

Reste a voir si ca fonctionne...

[invite1a47bfa2]

ca fonctionne!

J'arrive a chargé mon .hex via tftp...!

Par contre, il me reste un petit souci :

Existe-t-il une fonction C permettant de reseté le PIC afin qu'il relance le bootloader ?

Merci pour votre aide !

Alex

[RISC]

Salut,

Il existe effectivement une fonction C appelée...Reset() car la famille PIC18 possède l'instruction de reset SW.

a+

[invite1a47bfa2]

J'ai un souci avec la fonction Reset() ...

Lorsque je fais un reset hard de mon Pic, le bootloader s'execute bien, et je peux chargé mon .hex via tftp !

J'ai codé, dans le programme de mon .hex une fonction qui, à la reception d'une trame UDP spécifique, renvoie une trame UDP qui confirme la bonne reeption de l'ordre et Reset le PIC par l'utilisation de la fonction Reset();

Lorsque ce Reset soft est executer pour la premiere fois, le bootloader s'execute bien et je peux rechargé un .hex. Si aucune commande de chargement tftp n'est detecté, mon programme redémare !

Jusque la, tout va bien !

Par contre, si je redemande le reset soft par UDP, celui ci semble s'executer mais relance directement le programme contenu dans le .hex du PIC sans passé par le Bootloader.

Si je tente de chargé le .hex tout plante....

Je suis alors obligé de débrancher/rebrancher l'alim du PIC et de rechargé mon .hex

[invite1a47bfa2]

Bon, je n'ai pas reussi a trouver le problème qui fait que ca ne marche pas, par contre, comme mon programme est articulé autour du TCPIP Demo App, j'ai une option qui permet une reprogrammation quand le soft tourne (sans passer par le bootloader...) !

Alex

[RISC]

Salut,

J'ai jeté un oeil au code du Reset et j'ai trouvé pourquoi il saute à ton application.
Dans le fichier Main.C de la stack 5.25 tu verras à partir de la ligne 286 :

	// If the application reset for some reason and set the 
	// !POR bit, then immediately jump out of the bootloader and 
	// enter the application.
	if(RCONbits.NOT_POR)
	{
		// Change the PC to the application start vector, if an application has been bootloaded
		if(dwJumpInstructions[0] != 0xFFFFFFFF)
		{
			RCON = vExitRCONState;
			dwvNewPC.Val = (DWORD)&dwJumpInstructions;
			PCLATU = dwvNewPC.v[2];
			PCLATH = dwvNewPC.v[1];
			PCL    = dwvNewPC.v[0]+1-1;		//+1-1 is required to prevent C18 from using MOVFF instruction, which cannot move to the PCL register
		}
	}

Le bit POR est testé et c'est lui qui fait que tu sautes direct dans l'application. Il faut donc pas que ce bit soit vrai.
C'est peut-être que ta carte a été éteinte entretemps ?
Mets un point d'arrêt à cette fonction et si tu entres dedans c'est que le bit à la mauvaise valeur. Seule l'instruction Reset modifie les bits de RCON pour savoir la cause du Reset...

Un vecteur est écrit à ce moment là donc ci cela n'a pas lieu cà plante ton appli...

a+

[RISC]

Re,...

Ne pouvant éditer mon message précédent je continue ici.
Plus loin dans le fichier main.c (à partir de la ligne ) il semble mentionné qu'on puisse manipuler les bits qui indiquent la condition du Reset

Analyse aussi la boucle principale du main.

	while(1)
	{
		// Wait for a packet to arrive
		do
		{
			ClrWdt();

			// Jump out of the bootloader and into the application 
			// if BOOTLOADER_TIMEOUT elapses (and an application exists)
			if(GetTime() - dwBootloaderExitTimer >= BOOTLOADER_TIMEOUT)
			{
				// Change the PC to the application start vector, if an application has been bootloaded
				if(dwJumpInstructions[0] != 0xFFFFFFFF)
				{
					// Make sure that when we exit the bootloader, the RCONbits.NOT_POR bit is correctly set (0 for real POR, 1 for any other reason)
					vExitRCONState = RCON;
					if(vExitRCONState != 0x3Cu)
						vExitRCONState |= 0x02;

					// NOT_POR must be set for us to exit the bootloader
					RCONbits.NOT_POR = 1;
					Reset();
				}

Je pense qu'il faut revérifier la procédure du bootloader dans la documentation de la stack.

a+