EasyPIC8 and Mikrobasic IDE Debug not working

[dangerous]

Hi,

I am having similar issues to this post: viewtopic.php?f=233&t=76600&p=305367&hi ... IC#p305367 The response there implies that easyPIC8 debugger should work with MikroBasic IDE.

I am using the latest version of MikroBasic and fully updated Windows 10 21H2, Codegrip V1.5.1, suite up to date. Micro is PIC 18F45K22 running internal oscillator. EasyPIC8 has external 12vDC supply to the power socket.

I have an easypic7 which works fine for both programming and real time debugging directly from the IDE, however using the easyPIC8, I cannot acces the debugger. I am using the debug/propgram USB port to my PC.

On the easyPIC8, the DBGSEL switch is set to on-board. GPIO switches for DIP40 are set to prog/debug, MCLR set to Reset. RB 6 & 7 switches are set to mid position. Osc is set to GPIO (no crystal used).

I have set the Codegrip otions to WiFi off and USB enabled. I have set the porgrammer debug options in Mikrobasic to "Codegrip for PIC", and can now program directly from the IDE via Codegrip. I previously had to manually load the hex and ihex from the program files to Codegrip before programming. Programming mode is set to Vdd first entry mode, protocol (fixed) as ICSP, Speed 4MHz, but tried all options down to 500KHz.

Power, USB link and Active LEDS are all lighted.

If an ICD file is loaded, the blue LED stays on. I can only reset it by Power off button or re-programming with a Release version of the program. Reset has no effect on the LED. If a release version is loaded, once programming is complete, the blue LED extinguishes.

When RUN / Start Debuger is selected in MB, the message "MikroElektronica ICD hardware not found" message box is displayed. If power has been cycled Blue LED lights and stays on.

Sometimes I have to re-detect the USB with the Codegrip SCAN DEVICES tab before I can re-program after a power off reset.

I have tried every way to ensure that the debugger should be working, including reset and power off reset to the EP8 board after programming.

Have I missed some other vital setting that needs to be done either in CodeGrip or the IDE?

Any help would be appreciated as curently I am struck with the EP7 for debug.

[filip]

Hi,

Which version of the CODEGRIP Firmware are you using ?

Download the 1.3.0 version of the CODEGRIP Suite from this link:
https://s3.us-west-2.amazonaws.com/shar ... -win64.zip

If you already have a newer version of CODEGRIP Suite uninstall it.
Disconnect from the internet and install the 1.3.0 version (in offline mode).
Then perform debugger firmware downgrade from the newly installed 1.3.0 version.

Also, copy the DLL file from the attachment to the installation folder of the compiler.

Only then you will be able to use a CODEGRIP as a debugger tool through the mikroBasic PRO V7.60.

Regards,
Filip.

[dangerous]

Thanks Filip,
I will do this on Monday as all my kit is at work.

[dangerous]

Hi Filip.

I uninstalled V 1.5.1 no problem.

I downloaded and installed V1.3.0 (it shows as V1.3.1 in the installer) as suggested. It will run but the firmware shows as 1.5.0 and hardware V1.0.0 in CodeGrip/configuration tab

You say to downgrade the firmware of the debugger. How can I downgrade the debugger firmware as this does not appear to be an option? Is another file needed?

Does that need doing before changing the dll? If I change the dll as installed with V1.3.0 (950KB) to the supplied one (761Kb) it no longer runs. I assume it is because of the dll change. I tried restarting after changing the dll but still got the same message.

After changing it, I cannot open codegrip at all (error message Application cannot start 0xc000007b). Google suggests this can happen if 32 bit and 64 bit programs get mixed somehow. I am confused again.

[filip]

Hi,

You say to downgrade the firmware of the debugger. How can I downgrade the debugger firmware as this does not appear to be an option? Is another file needed?

Connect the board to PC, open CODEGRIP Suite, go to Help -> Updates -> CODEGRIP tab, press scan devices, power cycle the board and the firmware update will begin.

Regards,
Filip.

[dangerous]

Thanks Filip,
I will try next Monday

[dangerous]

Hi Filip,

I had already uninstalled V1.5.1 of codegrip and installed the version indicared which is V1.3.1 (not 1.3.0).

I followed your method to downgrade which seems to have worked. Codegrip is now showing as V1.3.1.

I renamed the orignal dll to codegrip-dll-core.old and installed the supplied dll after unzipping.

The same error message stil appears when trying to start Codegrip after changing the dll file. Microbasic does not recognise the programer or debugger (option greyed out). Re-instating the dll that came with V1.3.1 allows Codegrip to start but still is not seen by Mikrobasic.

I also tried removing the re-named codegrip-dll-core.old file but that had no effect.

I have run out of ideas how to get MB & Codegrip to work as a debugger. Can you help further please?

Error msg.pdf

(1.61 MiB) Downloaded 55 times

[filip]

Hi,

Can the CODEGRIP Suite see the CODEGRIP programmer in the list ?

Regards,
Filip.

[dangerous]

Hi Filip,

I just re-installed v1.3.1 as I had deleted the installed dll when I replaced it.

Now it works with the original dll as installed, but changing it to the one supplied stops it working with the applciation cannot start message box and the same error message.

Mikrobasic now sees the programmer and dbugger and appears to work fine as installed.

The attachement has the 2 dlls in it .new being the extra one supplied and .installed is the original one. Is it Ok to leave the installed dll in place as it seems to be fine?

[dangerous]

Hi Filip,

It seemed to be OK yesterday but today Ports C & D are getting wrongly programmed and the debugger is not working properly.

I have tried loading the program directly through Codgrip rather than from Mikrobasic and the result is still the same.

Any more ideas?

[filip]

Hi,

Can you explain what do you mean exactly by " getting wrongly programmed and the debugger is not working properly" ?

Regards,
Filip.

[dangerous]

Hi Filip,

I will confirm what happens as I have re-loaded the program again.

What do I need to change re the dll? It prevents the program from starting if I just replace the distributed one for the one in the file.

Do I need to change anything else or should it work without changing now the firmware has downgraded?

[dangerous]

Hi Filip,

We have conducted several tests now and have reached the conclusion that the 40pin socket has intermittent connections to the board from some pins of ports C & D. This has lead to confusion as some leds worked but some did not, however using a meter showed continuity as a result of the slight pressure needed to make contact with the base pin.

It appears that removal and replacement of the IC has damaged the tracks as, unlike the earlier EasyPic series, the EP8 uses turned pin bases that require considerable force to insert and remove the IC. This results in the board flexing which may have damaged the connections.

There is no obvious way to replace the socket with the alternative base as used in the earlier versions of EasyPic. This problem seems to have now rendered the 40pin application useless as some pins on D and C are inactive.

Do you offer a repair service for these boards, as it has had little use, and was quite expensive?

We do feel that the use of turned pin bases seems like a backward step especially for the larger 28 or 40 pin devices, simply owing to the force needed to insert or remove them.

Surely the purpose of a devlopment board is to allow different ICs to be used for development which necessitates removal of one chip to try another.

Are there any plans to use ZIF sockets for future builds, or offer these as an option?

There is also the issue that the latest version of CodegGrip does not work with the EP8 for debugging without downgrading the firmware and using an earlier version of the program.

[filip]

Hi,

We offer repair service at Mikroe, please submit your request on our HelpDesk.

As for the ZIF sockets, I will speak to our development team, this is a good idea.

Regards,
Filip.

[dangerous]

Hi Filip,

Back to the EP8 issues again.

When I load my quite large program with 8 modules + main,(total ROM = 7952, RAM= 630 ) in debug, the unit stops, presumably at a break point I set, but the cursor jumps to the start of the main program and stays there. It does flash if I single step but the PC indication stays at PC = 0x001BA6 which is where it starts when the debugger is restarted.

I made a simple program to prove all portsa,b,c,&d which is seen below and that works in debug and release. This proves that we sorted the bad connections to portd. It simply writes data to the EEprom after ckearing it then reads it back to the ports C & D.

I can upload the whole larger program if you would care to look but not on this forum as it is commercially sensitive in parts. It runs fine on EP7 and mikrobasic V7.6.0. but whist EP8 programs it fine it will not debug with EP8.

I followed your instructions to downgrade the firmware to V1.3.1 for Codegrip, but with the dll you supplied copied in, it refused to work at all. Not sur eif this is part of the issue.

Is Codegrip intended for NATCO rather than MikroBasic, or is there a patch due to fix the required downgrade? Having use MB since 2005 I am a bit reluctant to change to a nes system.

As always your help would be appreciated.

Code: Select all

program CGT2

' Declarations section 

  dim i,j,nbo,nbi as byte
  dim ebuff as byte [256]

main:
'   Main program 
  OSCCON = 0x70
  PLLEN_Bit = true
  ANSELA = 0
  ANSELB = 0
  ANSELC = 0
  ANSELD = 0
  porta = 0
  portb = 0
  portc = 0
  portd = 0
  lata = 0
  latb = 0
  latc = 0xff
  latd = 0xff
  trisa = 0
  trisb = 0
  trisc = 0
  trisd = 0
  for i = 0 to 0xFF
     EEprom_write(i,0xFF)      'erase eeprom
  next i
  for i = 0 to 9
     lata = not lata
     latb = not latb
     latc = not latc
     latd = not latd
     delay_mS(250)
  next i
  j = 0
  for i = 0 to 0xFF
     nbo = i
       eeprom_write(j,nbo)    'writes 0 to 0xFF to EEprom
     inc (j)
  next i
  nop
  i = 0
  latc = 0
  for j = 255 to 0 step -1
    nbi =  EEprom_read(j)
    ebuff[i] =  nbi
    latc = nbi
    delay_ms(20)
    inc (i)
    nop
  next j
   for j = 255 to 0 step -1
    nbi =  EEprom_read(j)
    ebuff[i] =  nbi
    latd = nbi
    delay_ms(20)
    inc (i)
    nop
  next j
    for j = 0 to 255
    nbi =  EEprom_read(j)
    ebuff[i] =  nbi
    latc = nbi
    delay_ms(20)
    inc (i)
    nop
  next j
   for j = 0 to 255
    nbi =  EEprom_read(j)
    ebuff[i] =  nbi
    latd = nbi
    delay_ms(20)
    inc (i)
    nop
  next j
  nop
  Latc = 0
  Latd = 0
 while true
    latc = not latc
    latd = not latd
    delay_mS(100)
    nop
  wend
    
  
end.