GP32 Flash problem

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

GP32 Flash problem

4,251件の閲覧回数
Guilly
Contributor I
Hi,
I am having some problems with a few GP32, and their SCI, for transmitting and receiving messages at a fixed baudrate. The problem is that, depending on where I start flashing the application (tried on 0xC000, 0xC800, 0xD000, and 0xD800) the device does or doesn´t work... When I use a sniffer to see the transactions, all the messages are correctly formed, and contain valid data (I put the sniffer right on the uC pins), but the uC randomly acts as if they were incorrect.
Anybody has ever seen something like this ???

Greetings,
Sebastián
ラベル(1)
0 件の賞賛
返信
5 返答(返信)

1,090件の閲覧回数
Alban
Senior Contributor II

Sebastian,

If you are storing this data in Flash:
Have a look at the flash programming routines you use and see if you respect the timings recommended in the datasheet.

To confirm, you can toggle a pin port at each stage and measure the time with an oscilloscope probe.

If you are not using Flash dynamically (meaning not for DATA but only static software), I don't have the slightest clue about what is going on :smileysurprised:

I suggest you use the debugger to trace the flow of the software and see the content of registers ton understand the trouble. For SCI reception/send, you will need to make a breakpoint rather than step by step.
You only have ONE breakpoint on HC08 (BRK module) therefore you need to remove (and not only disable) the previous bkpt before putting another one on CodeWarrior, otherwise the debugger will argue.

Cheers,
Alban.

0 件の賞賛
返信

1,090件の閲覧回数
Guilly
Contributor I


Alban wrote:

Sebastian,


If you are storing this data in Flash:
Have a look at the flash programming routines you use and see if you respect the timings recommended in the datasheet.


To confirm, you can toggle a pin port at each stage and measure the time with an oscilloscope probe.


If you are not using Flash dynamically (meaning not for DATA but only static software), I don't have the slightest clue about what is going on :smileysurprised:


I suggest you use the debugger to trace the flow of the software and see the content of registers ton understand the trouble. For SCI reception/send, you will need to make a breakpoint rather than step by step.
You only have ONE breakpoint on HC08 (BRK module) therefore you need to remove (and not only disable) the previous bkpt before putting another one on CodeWarrior, otherwise the debugger will argue.


Cheers,
Alban.






The data I am storing in flash is no dynamic... The weird thing is it seems that the SCI of the GP32 is not reading the bits correctly, as with a simple sniffer I made with a max232, I verified the strings in my PC... In different baudrates, it may ( or may not ) work, and if I put exactly the same source code starting in a different Flash address, the results are also different...

Greetings
Sebastián
0 件の賞賛
返信

1,090件の閲覧回数
rhinoceroshead
Contributor I
Does metrowerks come back to you saying that it couldn't flash 8000 - 8200 or something like that because the flash is bad or protected?  It seems like I saw this happen before.  Are you using the 32 kHz crystal going into monitor mode with the startup vector blank?  Or are you going in with the 4 Mhz crystal?
0 件の賞賛
返信

1,090件の閲覧回数
Guilly
Contributor I


rhinoceroshead wrote:
Does metrowerks come back to you saying that it couldn't flash 8000 - 8200 or something like that because the flash is bad or protected? It seems like I saw this happen before. Are you using the 32 kHz crystal going into monitor mode with the startup vector blank? Or are you going in with the 4 Mhz crystal?




I am using the full monitor mode, in the development stage. I have never heard about 8000 - 8200 flash locations damaged, but my app uses it for storing some parameters while running. I will try moving them into a different flash zone...
0 件の賞賛
返信

1,090件の閲覧回数
Alban
Senior Contributor II
Hi guys,
 
The feedback you might have had from Metrowerks was for you to try an other zone, IF the memory had been damaged at this place.
Only reasons for the memory to be damaged there or anywhere else would be the user or the embbeded software not respecting memory programming timing or max number of prog-erase cycles.
 
Let's say the applications software edit variables in the area and the Flash timings are incorrect, you can reduce the life of the memory cell dramatically !
 
These memories are tested before leaving the factory on each device.
 
Cheers,
Alban.
0 件の賞賛
返信