| View previous topic :: View next topic |
| Author |
Message |
georpo
Joined: 18 Nov 2008
Posts: 278
Location: Athens, Greece.
|
|
 Posted: Wed Oct 07, 2020 2:29 am |
 |
|
OK, I got it.
on the working board with the FJ16, after programming only the bootloader, address 0x0C00 says bra 0x000C00 also.
But after downloading firmware with teraterm this changes to goto 0x000E5E.
The FJ48 board stays to bra 0x000C00 even though it writes data further below...
So...what can I do now? 
Maybe order a PIC24FJ64GA002 ? 
_________________
George. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19221
|
|
| Posted: Wed Oct 07, 2020 3:28 am |
|
|
Yes, the goto 0xc00, is the 'dummy' application program built into the
bootloader:
| Code: |
void application(void)
{
while(TRUE);
}
|
Which of course is a permanent loop....
So the code is loading.
I've just tried pulling the hex file you posted into the MPLAB simulator, and
with a call to it from the bootloader, it is merrily being called. The physical
code is after the area for the interrupt table (the instruction at 0xC00 is
a jump to this). So I'm now wondering why this doesn't work when the
F16 version does...
Now that the serial runs OK for the bootloader, really tells us the new
board does work. Otherwise I'd be getting very suspicious you have a
hardware issue here. |
|
|
georpo
Joined: 18 Nov 2008
Posts: 278
Location: Athens, Greece.
|
|
| Posted: Wed Oct 07, 2020 3:35 am |
|
|
I am thinking of putting an FJ16 to the new board just to verify it works but I do not think this is the problem.
I will double check all the above and come back.
In the meanwhile if you have any ideas please share with me.
Thank you very very much for taking the time to deal with my problem and for the step by step approach.
Really appreciated!
_________________
George. |
|
|
georpo
Joined: 18 Nov 2008
Posts: 278
Location: Athens, Greece.
|
|
| Posted: Wed Oct 07, 2020 3:46 am |
|
|
Once again I verified that the FJ16 board changes the infinite loop to a goto...
And the FJ48 board fills with data after teraterm download but the infinite loop stays there at 0x0C00.
A little further below at 0x0C30 it has a goto 0x000E1A though...
Just checked with the FJ16 again. It also has a goto 0x000E1A at 0x0C30 so this is no big deal.
_________________
George. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19221
|
|
| Posted: Wed Oct 07, 2020 4:16 am |
|
|
I begin to get suspicious that you may have found one of the chips that
has a fault with the automatic memory erase.
There was a fault at one point, that certain chips did not correctly do the
program memory erase.
This would then mean that the dummy code at address 0xC00 couldn't
be overwritten. The higher code would be OK, since the memory here
would be left erased after programming.
I'll have to dig out 5.049, and look at the erase function on the F16 and F48
and see if this is the problem. Suspect it is.... 
No, just compiled the code on both chips and it is identical. |
|
|
georpo
Joined: 18 Nov 2008
Posts: 278
Location: Athens, Greece.
|
|
| Posted: Wed Oct 07, 2020 4:32 am |
|
|
OK, things are getting weird.
I soldered an FJ16 to the "no working" board of the FJ48.
Copy-pasted the FJ16 working code, changed ONLY the #pin select and button define and now I have the same behaviour.
After downloading with teraterm, data is written but the 0x0C00 remain a loop.
I will check to see what these pins share in common. maybe they are also analog I do not know yet.
Again! The only difference is the serial pins and the button pin!
Also tested that serial works both ways.
_________________
George. |
|
|
georpo
Joined: 18 Nov 2008
Posts: 278
Location: Athens, Greece.
|
|
| Posted: Wed Oct 07, 2020 4:49 am |
|
|
So, finally.
The "no working" board of the FJ48 with the FJ16 soldered is working with the bootloader now that I changed the #pin select for the serial!
Working:
| Code: |
#pin_select U1TX = PIN_B14
#pin_select U1RX = PIN_B8
|
NOT Working:
| Code: |
#pin_select U1RX = PIN_B2
#pin_select U1TX = PIN_B4
|
GO figure...
I will now place the FJ48 again with the new #pin_select
_________________
George. |
|
|
georpo
Joined: 18 Nov 2008
Posts: 278
Location: Athens, Greece.
|
|
| Posted: Wed Oct 07, 2020 5:21 am |
|
|
AND YES!!!
The fj48 on its board working with the bootlader!
Problem is the #pin select somehow.
And verified again.
working:
| Code: | #pin_select U1TX = PIN_B14
#pin_select U1RX = PIN_B8 |
not working | Code: | #pin_select U1RX = PIN_B2
#pin_select U1TX = PIN_B4 |
even though serial communication works both ways for both.
_________________
George. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19221
|
|
| Posted: Wed Oct 07, 2020 7:03 am |
|
|
You are changing the #pin select on both the bootloader code, and the
test code?. If not, you need the fuse NOIOL1WAY. Otherwise the
running code will not be able to 'change' the allocation (it will have been
'locked' by the bootloader setting). |
|
|
georpo
Joined: 18 Nov 2008
Posts: 278
Location: Athens, Greece.
|
|
| Posted: Wed Oct 07, 2020 9:55 am |
|
|
Yes of course.
the #pin select is exactly the same on bootloader and test code
even though I noticed that it keeps the setting from the bootloader code no matter what #pin select I choose in test code.
If I do not set the #pin select in the test code it does not compile because it needs to know the pins for #use rs232.
Could you explain why with the same code, same board, same microcontroller, same serial link, same teraterm program, it works with one set of pins and does not work with the other?
Both sets of serial pins are tested for bidirectional operation.
As soon as I change the #pin select and connect the cable to the other pins, it works. Or else the infinite loop does not change to a goto even though there is data occupying the device after download of code.
_________________
George. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19221
|
|
| Posted: Wed Oct 07, 2020 10:03 am |
|
|
The standard answer would be that B2 or B4 is already in use on the chip.
However since the chips are the same family this doesn't apply.
It may simply be something really silly. You have got both Vss & Vdd
connections made?. The larger chip will draw more current than the
smaller one, and current during a memory erase/write is higher than
normal operation. You may be seeing an 'implication' of this not being
quite correctly supported by the hardware. Similarly a slightly 'below par'
capacitor on VddCore can also give oddities like this. |
|
|
georpo
Joined: 18 Nov 2008
Posts: 278
Location: Athens, Greece.
|
|
| Posted: Wed Oct 07, 2020 10:19 am |
|
|
No, the pins are not in use anywhere else.
Capacitor on VddCore is 10uF.
Power from power supply so it is more than enough.
I really cannot get it...
I repeat that both sets of pins are tested for bidirectional operation.
_________________
George. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19221
|
|
| Posted: Wed Oct 07, 2020 12:43 pm |
|
|
10uF, but what ESR, and how close to the chip?.
You haven't answered about all the Vdd/Vss connections. |
|
|
benoitstjean
Joined: 30 Oct 2007
Posts: 543
Location: Ottawa, Ontario, Canada
|
|
| Posted: Wed Oct 07, 2020 12:55 pm |
|
|
If I may add my comments, I've simply contacted CCS in the past and asked them if they had known working bootloader code for the PIC24EP series and they sent me some files which worked immediately.
Ben |
|
|
georpo
Joined: 18 Nov 2008
Posts: 278
Location: Athens, Greece.
|
|
| Posted: Wed Oct 07, 2020 2:05 pm |
|
|
If you mean the Vdd/Vss pins of the chip, of course they are all connected and have capacitors close to the pins.
The board with the FJ48 is a WiFi device with Oled, EEPROM , Buttons etc and through the serial pins (that do not work with the bootloader) it communicates with the WiFi module and handles all the At-commands, connect, send/receive data etc and all this is working just fine.
If there was a hardware problem I would have noticed so far.
I can not figure out why it does not work with the bootloader when I select these pins. Ttelmah I guess you are right and it is something very silly but I do not know what. I will try again tomorrow and then maybe I will redesign the board to use the other pins.
But still it remains a mystery.
_________________
George. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
