Address errors with QFN PIC24FJ32GA102 but not DIP PIC24FJ32GA102

[John Catsoulis]

Hi,

I have an unusual problem. I am consistently getting an address error with FlashForth running on a PIC24FJ32GA102-I/ML. This is a QFN part, and I'm only getting this error on the QFN part, not the DIP version of the same processor.

FlashForth starts up, prints its banner message. The prompt works fine when you press return. I can leave it running at the prompt for hours without an problem. Basic stack ops work, but SOMETIMES cause an address error. 1 1 + . works fine. Typing 1 by itself is fine, but...
1
42
... might cause an address error after pressing return on 42.

Many words work without an error ...
decimal ' here 1+ . .s prompt
... and so on are fine. However...

1 @

... will trigger an address error. "words" will print out most of the dictionary, but will trigger an address error toward the end, and restart FF. Any colon definition will trigger an address error. Even...

: test ;

... will trigger an address error restart.

here .

... does not trigger an address error, but returns a value of 0 to the stack.

The PIC24FJ32GA102-I/ML is a QFN28 part, and the error seems specific to this part. If I run FlashForth (same source, same config) on a PIC24FJ32GA102-I/PT (DIP package), I do NOT get address errors and FF works fine. These processors are identical except for the package. I have read back FlashForth from the flash of both parts, and flash contents are identical. So it is not an issue with the flash not burning correctly.

I have tried both v1.34 and v1.35 of the xc16 compiler, with the same result.

The circuits are identical, same compiler, same source code, same config file. Power rail is very clean. There is nothing interfaced to the PIC except a status LED and a USB bridge on the UART pins, and the UART works fine.

I can run test software in C on the PIC24FJ32GA102-I/ML and there are no errors. The hardware checks out.

If I do a debug build of FlashForth, the address error goes away on the PIC24FJ32GA102-I/ML. FF works reliably with a debug build. With a production build, the address errors come back.

I have done a RAM test (write/read) for all RAM locations on the PIC24FJ32GA102-I/ML and it checks out. No errors. I let the RAM test run in a loop for an hour... no errors.

The config file has the following address allocations:

.equ FLASH_SIZE,0x5400 ; 32K Flash, size in bytes without the high byte
.equ RAM_SIZE, 0x2000 ; RAM size in bytes (8K)

Since I have been unable to find what the issue is using a debug build, I used a status LED to try to track down where the error is happening. Turn the LED on before a bunch of instructions, then turn the LED off, and thereby home in on where the address error is being triggered. The forth code I was using to trigger the address error was:

1 @

The address error seems to be happening after the return instruction at the end of PFETCH1, but I'm am not sure where beyond that.

I'm wondering if anyone has seen anything like this before or has any suggestions? The problem seems specific to the QFN part, as it does not happen in the "identical" DIP part. I do not think it is a bug in FF, nor is it a hardware issue. Any ideas?

Thanks.

John

Config files attached. Flashforth source is unmodified.

[Mikael Nordman]

I think you have hit the bug in ASM30.
You need to have the listing option enabled in order for ASM30 to generate correct code.

I have reported this bug to microchip many years ago and they agreed to fix it.
If they did, they put it back later :-)

Microchip have not been concerned about ASM30 or linker bugs, as long as the C complier works correctly....

[John Catsoulis]

Thanks Mikael. That fixed it. :) Much appreciated.

[John Catsoulis]

Hi Mikael, it seems the problem isn't fixed. The quick tests I did seemed to work, but I'm still getting an address error in certain circumstances. For example...

  ok<#,ram> 
  ok<#,ram> 
  ok<#,ram> 
  ok<#,ram> 
: test ; AS FlashForth 5 PIC24 14.03.2017

(Note: I'm using xc-16-as rather than the obsoleted asm30, and I'm seeing the same problem.)

Any suggestions?

Thanks.

[Mikael Nordman]

Yes, Microchip has the same bug also in xc16. I am also using xc16, not asm30. Good job Microchip.

Can you try FF with the config file in Git ? Just change the memory size and comment out uart2.

What have you done before compiling test? Just a clean burn and boot ?

Have you checked the exact chip versions and possible Microchip errata?

Is the situation now that the PDIP part works, and QFN part not ? With the same build ?

Can you upload the listing file of the not working build ?

[John Catsoulis]

Can you try FF with the config file in Git ? Just change the memory size and comment out uart2.

Tried that, same result.

What have you done before compiling test? Just a clean burn and boot ?

Yes. Clean build, burn and restart. I have also done a build and burn on the DIP to confirm that the build is good, then burnt that same file to the QFN and had it fail. I have then read back the flash from both parts and confirmed they are identical.

Compiling test fails with no other activity after restart:

E FlashForth 5 PIC24 14.03.2017

: test ; AS FlashForth 5 PIC24 14.03.2017

Have you checked the exact chip versions and possible Microchip errata?

Yes. Device revision is A2 (0x2). There are no errata listed that seem applicable to this problem. http://ww1.microchip.com/downloads/en/DeviceDoc/80000470j.pdf

Is the situation now that the PDIP part works, and QFN part not ? With the same build ?

Yes, identical build.

Can you upload the listing file of the not working build ?

I have attached the three source files.

I'm coming to the conclusion that it has to be an issue with the silicon on these QFN parts.

Thanks for your help Mikael.

[John Catsoulis]

Sorry, forgot the listing file. Attached.

[Mikael Nordman]

That compilation fails could be caused by the dictionary pointers being wrong.

here returning zero could be caused by the flash beeing zeroed, instead of erased before writing flashforth to the chip. Make sure that your chip programmer erases the flash before programming FF to the chip.

For FF to work correctly, the flash in the eeprom emulation area must be erased (=$ff) before FF starts up. If WARM finds $ff in the beginning of the eeprom emulation flash, it will reinitialize the dictionary pointers by executing EMPTY.

So you could try to boot the pic and say EMPTY.
That will reset the eeprom emuluation and the dictionary pointers.
flash here . should print $5c00

[John Catsoulis]

That seems to have worked. Thank you very much Mikael. I really do appreciate your help.