Page 13 sur 14

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 02 Aoû 2020, 09:29
de M4x1m3
Merci zardam. J'ai re-jeté un œil au code. Je l'ai passé en Single pour tester, voir si ça changeait quelque chose. Par rapport au changement de mode, Epsilon le fait. Je vais essayer de repasser en QSPI et d'ajuster les timings.

Edit: Merci beaucoup, j'ai réussi à intégrer ton patch, j'arrive à lire et à écrire sur la flash externe. Je vais juste devoir batailler avec LD pour déplacer une partie du système sur la flash externe comme sur N0110...

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 02 Aoû 2020, 11:21
de zardam
Super !

Attention, l’exécution depuis la flash externe est assez lente sur la n0100. J'avais porté le script de linker de la n110 pour essayer, et la différence était assez flagrante.

En plus, le STM32F412 n'est pas capable de debugger du code dans la flash externe, et c'est assez pénible...

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 02 Aoû 2020, 11:58
de zardam
PS : j'ai retrouvé la branche, et le changeset : https://github.com/zardam/epsilon/commi ... 8702fc7ba2

C'est un peu vieux, mais je n'ai pas mieux.

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 02 Aoû 2020, 14:04
de M4x1m3
J'ai l'impression que me patch ressemble étonnamment au tiens, mais le mien ne fonctionne pas. J'ai essayé de virer le driver du mode examen (et la section associée dans le fichier du linker) sans succès. Je vais essayer de compiler ta version et de la lancer sur ma N0100++...

Edit1: Désolé si j'ai l'air de poser des questions débiles, mais je navigue un poil à l'aveugle, mon stlink v2 ne fonctionne pas (donc je peux pas debug), j'en ai commandé un nouveau mais avec le covid tout ça je l'aurais pas avant deux semaines, et je n'y connais pas beaucoup en tout ce qui est très bas niveau...

Edit2: Je comprends de moins en moins... Ta version ne marche pas chez moi...

Edit3: Je viens de test avec la Winbond, marche pas non plus. C'est peut-être parce que j'ai dû faire une modif pour que ça link? Cf. patch joint.
Show/Hide spoilerAfficher/Masquer le spoiler
Code: Tout sélectionner
diff --git a/ion/src/device/n0100/flash.ld b/ion/src/device/n0100/flash.ld
index 00bf7b8d1..843a468ba 100644
--- a/ion/src/device/n0100/flash.ld
+++ b/ion/src/device/n0100/flash.ld
@@ -98,6 +98,7 @@ SECTIONS {
     *(.text._ZN3Ion6Device6Timing8shutdownEv)
     *(.text._ZN3Ion6Timing6msleepEj)
     *(.text._ZN3Ion6Device5Board17setClockFrequencyENS1_9FrequencyE)
+    *(.text._ZNK3Ion6Device4Regs3TIMINS1_8RegisterItEEE4BaseEv.isra.0.lto_priv.0)

     /* Optimization */
     */libgcc.a:(.text)

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 03 Aoû 2020, 01:33
de zardam
Il y a un souci dans le descripteur DFU :

Code: Tout sélectionner
diff --git a/ion/src/device/n0100/drivers/config/usb.h b/ion/src/device/n0100/drivers/config/usb.h
index f94bee902..f8cf2e8c7 100644
--- a/ion/src/device/n0100/drivers/config/usb.h
+++ b/ion/src/device/n0100/drivers/config/usb.h
@@ -15,7 +15,7 @@ constexpr static AFGPIOPin DmPin(GPIOA, 11, GPIO::AFR::AlternateFunction::AF10,
constexpr static AFGPIOPin DpPin(GPIOA, 12, GPIO::AFR::AlternateFunction::AF10, GPIO::PUPDR::Pull::None, GPIO::OSPEEDR::OutputSpeed::Fast);

#if EXTERNAL_FLASH_8M
-constexpr static const char * InterfaceStringDescriptor = "@Flash/0x08000000/04*016Kg,01*064Kg,07*128Kg/0x90000000/08*004Kg,01*032Kg,63*064Kg,64*064Kg";
+constexpr static const char * InterfaceStringDescriptor = "@Flash/0x08000000/04*016Kg,01*064Kg,07*128Kg/0x90000000/08*004Kg,01*032Kg,64*064Kg,64*064Kg";
#else
constexpr static const char * InterfaceStringDescriptor = "@Flash/0x08000000/04*016Kg,01*064Kg,07*128Kg";
#endif


63*064Kg -> 64*064Kg à la fin (le secteur pour le mode examen est utilisable sur la n100).

Ça fonctionne chez moi (avec un gcc 7).

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 03 Aoû 2020, 12:19
de M4x1m3
Ça me parait bizarre, parce que quand j'additionne avec le 63 je tombe sur 8192K (aka. 8M) alors qu'avec le 64 je tombe sur 8256K. Je vais voir.

J'utilise GCC 9 (directement du site d'ARM), est-ce que ça se peut que ça soit ça ?

Est-ce que tu peux me donner une image compilée que je puisse tester sur ma calculatrice ?

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 03 Aoû 2020, 19:05
de zardam
Effectivement, j'ai oublié le fractionnement du premier secteur, donc mon changement est incorrect.

Par contre, j'ai juste recompilé ta branche, avec le dernier gcc 9 de chez ARM et ça fonctionne très bien maintenant (alors qu'elle partait en boucle de reboot lors de mon premier essai).

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 03 Aoû 2020, 19:16
de M4x1m3
Peux-tu me fournir des binaires ? Comment flash-tu ? J'utilise ma version modifiée du projet tiplanet webdfu Numworks, peut-être que ça viens de là ?

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 03 Aoû 2020, 22:31
de zardam
Les binaires sont ici : https://we.tl/t-jNXXyLKIh2

J'utilise le target "epsilon_flash" du Makefile, et la calculatrice en DFU pour flasher.

Re: Challenge NumWorks++ | Flash chip hardware mod

Message non luPosté: 04 Aoû 2020, 08:47
de M4x1m3
Je ne sais plus quoi faire, surement un problème de soudure ou jsp, mais tes binaires ne marchent pas non plus. Comment ça se fait que j'arrive à faire tourner ta version d'epsilon avec giac... ?

Edit: J'ai doublé le diviseur de fréquence de la flash externe et ça marche, wtf ?