CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

PIC24 + enc28j60 freeze
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ttelmah



Joined: 11 Mar 2010
Posts: 13357

View user's profile Send private message

PostPosted: Thu Sep 28, 2017 11:16 am     Reply with quote

My guess is one of the memory addresses being given to the function is incorrect. Will then give an address trap. So it'll be the MOV instruction.

Printout the addresses involved before the call, and use the CCS read_program_memory function. I'd suspect the pointer is not being placed on an even boundary correctly.
pomakmrysen



Joined: 14 Sep 2017
Posts: 10

View user's profile Send private message

PostPosted: Thu Sep 28, 2017 12:03 pm     Reply with quote

This is the function

Code:
void memcpypgm2ram(unsigned int8 *pDst, rom unsigned int8 *pSrc, size_t n)
   {
      unsigned int8 c;
      debug_printf(debug_putc, "\r\nmemcpypgm2ram(%LX,%LX,%LX) DSRPAG=%LX ", pDst, pSrc, n, DSRPAG);
      while(n--)
      {
         c = *pSrc;
         debug_printf(debug_putc, "%02X ", c);
         *pDst = c;
         pDst++;
         pSrc++;
      }
      debug_printf(debug_putc, "\r\n");
   }


and with these parameters are loaded

Code:
MPFS MPFSOpen(BYTE* file)
{
    MPFS_ENTRY entry;
    MPFS FAT;
    BYTE fileNameLen;
   
    debug_mpfs(debug_mpfs_putc, "\r\nMPFSOpen() '%s' ", file);

    if( mpfsFlags.bits.bNotAvailable )
    {
        debug_mpfs(debug_mpfs_putc, "NOT AVAILABLE");
        return MPFS_NOT_AVAILABLE;
    }

#if defined(MPFS_USE_EEPROM) || defined(MPFS_USE_SPI_FLASH)
    FAT = MPFS_Start;
#else
    FAT = (MPFS)MPFS_Start;
#endif
   
   _currentFile = MPFS_INVALID;

    // If string is empty, do not attempt to find it in FAT.
    if ( *file == '\0' )
        return MPFS_INVALID;

    //debug_mpfs("p1='%s'0x%LX ", file, file);

    file = (BYTE*)strupr((char*)file);
   
    //debug_mpfs("p2='%s'0x%LX ", file, file);

    debug_mpfs(debug_mpfs_putc, "START=0x%LX e=%X ", FAT, sizeof(entry));
   
    PSV_SAVE();
    PSV_GOTO(FAT);

    for(;;)
    {
        // Bring current FAT entry into RAM.
      #if defined(MPFS_USE_EEPROM)
           XEEReadArray(FAT, (unsigned char*)&entry, sizeof(entry));
      #elif defined(MPFS_USE_SPI_FLASH)
           SPIFlashReadArray(FAT, (BYTE*)&entry, sizeof(entry));
      #else
         #if defined(__C30__)
              memcpypgm2ram(&entry, (ROM void*)(WORD)FAT, sizeof(entry));


Where is the mistake ?[/quote]
Ttelmah



Joined: 11 Mar 2010
Posts: 13357

View user's profile Send private message

PostPosted: Thu Sep 28, 2017 12:13 pm     Reply with quote

I repeat the comment, use the CCS function.

It's all going to depend on how _everything_ is declared. You are the person writing the code, you have to debug it.
pomakmrysen



Joined: 14 Sep 2017
Posts: 10

View user's profile Send private message

PostPosted: Thu Sep 28, 2017 12:32 pm     Reply with quote

I am not writing the code, its compiler generated from project wizard . I try to run it.
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Fri Sep 29, 2017 3:17 am     Reply with quote

So, if I read this right, you are trying to use the CCS ported version of the Microchip TCP/IP stack with external EEPROM to hold your MPFS webpage image.

Won't work. At least not out of the box, unless the porting has been improved. I am pretty sure the trap you are seeing is an address trap, i.e. the code is trying to access unimplemented or invalid memory.

The CCS stack is a partial port of the Microchip stack, with limited capabilites. Much of the Microchip stack has not been ported to CCS. The Microchip code is there, but it will either not compile or won't run correctly. You simply have to set to and debugging it line by line. Not easy by any means but doable.

To get all this to work, and I did, I had to reimplement the PSV macros, re-roll the XEE routines and port TFTP support code, as being able to serve webpages is one thing, uploading them is quite another matter. It was a lot of work, weeks in fact, but I did get it working.
pomakmrysen



Joined: 14 Sep 2017
Posts: 10

View user's profile Send private message

PostPosted: Fri Sep 29, 2017 11:39 am     Reply with quote

Yeah its address trap but in internal memory not external eeprom. Do you have some code that will work on 24 ?
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Mon Oct 02, 2017 3:20 am     Reply with quote

pomakmrysen wrote:
Yeah its address trap but in internal memory not external eeprom. Do you have some code that will work on 24 ?


Yes, of course its a internal memory trap: the PIC hardware can't do anything about external eeprom. Not to mention that you should have told us you knew it was an address trap.

Yes, I have code that works on 24s, but I can not share it for commercial reasons. My point is that the TCP/IP stack as ported by CCS only works for very limited configurations. You, and I before you, have to suss out for yourself what's required to get other configurations to work.

What I can offer is support and confirmation that, albeit with a lot of work, it is possible to get the stack to do what you want it to do, and that the fault you reported was not, in fact, in the code you posted. Hint: yes, the problem shows up in MPFSOpen, and would also affect other routines were you able to get that far, but actually one big problem is in the PSV macros, such as PSV_SAVE, used by MPFSOpen (and other routines). Even if I gave it to you, my solution to the PSV macro issue probably won't work for you as you use SPI for both eeprom and LAN interface whereas my system used SPI for eeprom and parallel (PMP) for LAN interface. For my solution I also did what CCS did, i.e. only port/debug those parts of the stack I needed. I did not do a full port: it would have taken far too long.
jeremiah



Joined: 20 Jul 2010
Posts: 989

View user's profile Send private message

PostPosted: Mon Oct 02, 2017 7:09 am     Reply with quote

We had a similar problem with ported version of the CDC host library (ported from microchip). It was developed with the PIC18 in mind, so when we tried it on a PIC24, we had a few instances where some of the data structures were forced into a certain size and had 16 bit values located on odd addresses and being accessed (thus causing an address trap). I would start by looking at the type definitions of the structures being used and see if any of them have a mix of 8bit and 16 or 32 bit components. If they are packed structures, then accessing them will cause a trap on a PIC24.
oxo



Joined: 13 Nov 2012
Posts: 219
Location: France

View user's profile Send private message

PostPosted: Thu Oct 12, 2017 3:53 am     Reply with quote

The CCS ported code is flaky with DSPIC. I believe it doesn't respect some of the spi timing correctly.

Our solution was to rewrite the low level code using CCS spi functions entirely.

Now it works, and has been running in the field 24/7 for a couple of years.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group