FlashForth: for PIC and Atmega / Discussion / Open Discussion: What is the recommended tool version to build FF for PIC24?

Amt - 2021-09-07

Hi,
Could you share details on the toolchain and IDE that was used to build a working FlashForth kernel for a PIC24? I have some strange behaviour on Mplab v5.50 with XC v 1.35

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mikael Nordman - 2021-09-07

What strange behaviour ?
I am using XC16 1.35 and MPLABX 5.35. The build does not work correctly unless you enable the listing option for xc16-as.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amt - 2021-09-07

It seems to build correctly, but when I debug with a PicKit, the code randomly jumps to __AltMathError and then just loops back to GOTO __reset,__main

I'm trying to get FF working on a PIC24FJ256GA705 and also need to get the configuration right. It's set to not use alternative interrupt vectors and the clock source is set to internal RC @ 8MHz

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mikael Nordman - 2021-09-07

That sounds like you have not enabled the listing option. There is a stupid bug in xc16-as that it does not resolve label addresses correctly unless the listing option is enabled. The bug has been there since ASM30 and it has been faithfully carried over to XC16-AS.

Or do you have a working FF commandline ?

Last edit: Mikael Nordman 2021-09-07

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amt - 2021-09-07

I don't have a working FF commandline. The config file seems to map rp2 and rp3 for the UART.

The listing option (XC16 > xc16-as > list to file) looks to be enabled already. Is there anything else that could be wrong?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amt - 2021-09-07

When I quit the debugger and restart it, the code runs till EEWRITE (called from within DP_COLD).

My hunch is that it has something to do with the either the EEPROM emulation or the way flash memory is written.

Is EEPROM emulation enabled by default on PIC24? if not, how'd I enable it?

What additional configuration is needed to customize the flash write/erase to a chip? I suspect our issue is due to some mismatch in the erase page size.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amt - 2021-09-07

I'll post here with updates. Currently I'm validating the UART (did I connect the right pins? is the baud rate correct? etc)
So far it looks like my UART dogle doesn't receive anything. Even a static letter transmitted right after the UART is brought up.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mikael Nordman - 2021-09-07

Could you attach your config file ? I will try to compile for your chip.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mikael Nordman - 2021-09-07

The flash in your chip is different from the earlier FJ series. It seems more similar to to the E series, where the flash block size is 1024 lower words + 1024 upper bytes. The eeprom emulation is required to write two words each time. This is supported in the E series code.
Merging the config from the E series file from ".equ FLASH_ERASE," and onwards might work.

Last edit: Mikael Nordman 2021-09-07

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mikael Nordman - 2021-09-07

Here is an earlier find of the same problems.
https://sourceforge.net/p/flashforth/discussion/726813/thread/26513e1018/

Apparently my website has become faulty over time. I mean about supporting all chips...

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amt - 2021-09-08

I've attached the config file with this message. It's a c file that needs to be added to the source tab in the project view. The link is very useful, I had gotten the same "couldn't find alternate vector table address" error initially. The AIVTDIS = OFF is what resolves it (AIVTDIS is for enabling the alternate vector table).

Please also note that I've configured the oscillator settings to use an external 16MHz crystal.

BTW the newer xc16 compilers do not let us use the config keyword to set config bits in asm. They use pragmas in a separate C file. Going forward IMO, we should do this so that the latest / future compilers can be used.

configs.c

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Mikael Nordman - 2021-09-08
  
  I meant the all the FF config parameters.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Amt - 2021-09-09
    
    Oh, my bad! I've attached the FF config file that gets pulled for this chip.
    
    p24f_config.inc
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amt - 2021-09-08

"Apparently my website has become faulty over time. I mean about supporting all chips..."

Nah, I wouldn't call it being faulty :) In fact it's a good thing cause we're getting FF to work on more chips.

Let me compare the datasheets for the three chips, but I'll also test out the E series configs. Right now I'm validating the serial interface with a short code of my own (to confirm the pins and settings)

What do these constants do btw? I can crosscheck the settings against the recommended flash erase size / sequence given in the datasheet

.equ FLASH_ERASE, 0x4003 ; Erase one row (1024/1596/3072 bytes) .equ FLASH_WRITE, 0x4002 ; Write one row (128/196/348 bytes) .equ FLASH_WRITE_SINGLE, 0x4001;Memory word program .equ FLASH_WRITE_DOUBLE, 0x4001 ; Memory double word write .equ IBUFSIZEL, 0x0800 .equ IBUFSIZEH, 0x0400 .equ IBUFLEN1, 0x0100 ; Inner write loop .equ IBUFLEN2, 0x0008 ; Outer write loop .equ IBUFMASK, 0xf000
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Mikael Nordman - 2021-09-08
  
  These are the NVMCON function codes and the buffer sizes and the loop iteration values for reading and writing a whole flash block.
  I think those are the correct values.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amt - 2021-09-08

There is something wrong with the UART configuration in FF for this part. I don't see any toggles on the tx pin even after inserting an instruction to always write a random value to U1TXREG. Please find the attached c code where the TX pin was found to work correctly.

Here are the things I checked in the FF code so far:
1. The baudrate generator register value [it's correct]
2. The RPO/RPI mapping [It's correct, matches the values in my sample code]
3. The RPO/RPI unlocking sequence [it's correct]

main.c

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mikael Nordman - 2021-09-08

Use this

.equ TX1_BUF_SIZE, 0 ; Use 0 for unbuffered TX.

If it is larger than zero, an interrupt routine will perform the TX. Maybe the interrupts don't work correctly.

Other observations:
The FF code does not set the TRIS for output for the UART TX. Your C code does that. But according to the datasheet it is not needed. You could try it anyway.
FF initialises U1MODE to 0x8008. It is using the high speed BRG mode.
Just try hardcoding the stuff in WARM.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mikael Nordman - 2021-09-08

The 24FJ256GA705 standard linker file does not seem to support filling the AIVT automatically. Or it relies on some C compiler magic that does not kick in with FF.s.
On the other hand the FJ series setup in FF wants to use the AIVT for user defined interrupts. What a mess.
I wonder why microchip had to do this differently.

Other F(J) series linker files do fill the AIVT automatically.

For other chips lacking the AIVT completely, FF supports having the user IVT in RAM. Maybe that should be done for the GA, etc. chips also. Or all 24 and 33 series chips, just to be consistent..

There is also INT/ which can initialize the AIVT from the IVT, one vector at a time.

Last edit: Mikael Nordman 2021-09-08

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amt - 2021-09-09

Hi Makael, the spambot is deleting my messages. Here's an update on the UART issue:

The asm equivalent of the working C uart code was inserted at different points in the FF code (not simultaneously)

The UART transmitted data when the code was run right after reset, from inside __reset

The same code when run from within .ifdecl RPINR18, doesn't transmit anything.

My suspicion is on some initialization sequence between these two sections. Particularly the OSCCON writes in the __reset section which probably either disables the UART clock or puts it in some invalid configuration.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Mikael Nordman - 2021-09-09
  
  There are no writes to OSCCON. Only reads. It is just checking for the PLL to become stable before it continues.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Amt - 2021-09-09

There is something weird going on with the UART, maybe the part has some issue. I see that the UART code doesn't transmit anything if it's called after FILL_RAM.

It doesn't make sense, the RAM range is within spec and it doesn't help even when I use a lower value like 0x2000.

But, why would writing to user ram space affect the UART module at all? I don't get it

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mikael Nordman - 2021-09-09

Yes, quite strange. Keep kicking :-)
These parts have no errata for the UART. I checked.

Last edit: Mikael Nordman 2021-09-09

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mikael Nordman - 2021-09-10

Do you get it working in the MPLABX simulator ? I do. It prints out fine the startup printouts.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Amt - 2021-09-11
  
  The UART seems to work fine with no issues in the sim, but on the real device it doesn't, for some reason. I'm also a bit surprised that the c UART code works fine, given how I'm doing the exact same thing in assembly.
  
  Maybe it inserts some init code when compiling the c code. It's weird.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Mikael Nordman - 2021-09-10

This config works for me in the simulator.

p24fj_ga_config.inc

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

What is the recommended tool version to build FF for PIC24?

Forums

Help

What is the recommended tool version to build FF for PIC24?

What is the recommended tool version to build FF for PIC24?

Forums

Help

What is the recommended tool version to build FF for PIC24? document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

What is the recommended tool version to build FF for PIC24?