LCD stopped working!

[Sasha]

I made my midibox, and yesterday tried it with 4x16 and 4x20 LCDs. It was working great but suddanly when I changed back to first tested 4x16 module it stopped. It starting with blocks like before, when MIOS is booting, but nothing happends after. From time to time when i power it up it shows something like 2 demmaged blocks. I tested my midibox with few other modules which was working but nothing happends. I tried other power supply... nothing. I tested both LCDs on PC paralel port and both are working properly, so problem is on the box. Could it be MIOS or core. I checked wires and PCB also and it seams OK. What could be the problem? I didnt mention, except LCD box is working without any problems! I just started enjoing my LCD but happiness didnt last long :(

[Jidis]

Many here are better qualified to answer, but my guess would be the Core. I guess you don't have a means of re-blowing the loader or anything into the PIC, do you? ???

I had a messy Core a while back, and it booted OK for a while, but would intermittently boot to black blocks and crap. It started getting worse, and I think I asked about it in here (there were other similar posts as well). Sometimes if I rapidly threw the power at it, off & on a few times, the app would start OK. Desoldering and double checking, or swapping a bunch of parts got it up to spec.

Hope you can get it back!

George

[Sasha]

I have no functional programmer at home so i couldn`t reprograme it right away so that solution is out right now

I have one more question... I am testing reconfiguring, dumping sysx a lot since I get my box working I have a lot to learn and see in real life. Jidis said he got messy MIOS. Could it get messy of a lot of sysx sending and reconfiguring? Could MIOS get unstabile or demmaged after some time or a lot of dumping?Is there any precausions I must take care of?

[TK.]

Jidis said he got messy MIOS. Could it get messy of a lot of sysx sending and reconfiguring? Could MIOS get unstabile or demmaged after some time or a lot of dumping?Is there any precausions I must take care of?

Why should there especially in your case a problem with the bootloader if the LCD doesn't work anymore, there is no relation... in general - and I must highlight this - it is very very unlikely that the bootstrap loader gets messed up!

There are some protection mechanisms within MIOS and the bootstrap loader itself to prevent this. Therefore I think that this was a hint into the wrong direction - better to check the hardware connections carefully (and the jumpers at J3), because such errors are the common case (when you read this forum section), and therefore it cannot be suggested often enough.

Best Regards, Thorsten.

[TK.]

Btw.: you can ensure that MIOS is still complete by uploading the CRC application. It will print out a checksum at the LCD (ok, this doesn't help here), but it will also send the checksum via MIDI

Best Regards, Thorsten.

[Sasha]

I have uploaded CRC aplication, and I am not sure if I get it right is is working. If LCD isn`t problem i could see it on display but now I am not sure. I couldn`t find step by step instruction using it. Only thing i can see now is different sysx at the begining as you can see. Beside LCD box is working. Here is peace of code. 

PS. I recheck zilion times conection with multimeter and it is fine. PCB looks clean and healthy.

TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT             

    68080  4  14    240 Buffer:    8 Bytes    System Exclusive     

  SYSX: 240 0 0 126 64 0 1 247

    85191  4  --    176    9    66    1  ---  Control Change       

    86494  4  --    176    10  120    1  ---  CC: PAN             

    86549  4  --    176    10  121    1  ---  CC: PAN             

    87708  4  --    176    11    62    1  ---  CC: Expression       

    88636  4  --    176    12    24    1  ---  Control Change       

    88681  4  --    176    12    25    1  ---  Control Change       

    89636  4  --    176    13    88    1  ---  Control Change       

    90618  4  --    176    14    81    1  ---  Control Change       

    90653  4  --    176    14    82    1  ---  Control Change       

    90669  4  --    176    14    83    1  ---  Control Change       

    91439  4  --    176    15    71    1  ---  Control Change       

    91495  4  --    176    15    72    1  ---  Control Change       

    91528  4  --    176    15    73    1  ---  Control Change       

    92457  4  --    176    16    63    1  ---  Control Change       

    92501  4  --    176    16    64    1  ---  Control Change       

    95827  4  --    176    5    78    1  ---  CC: Portamento Time 

    97023  4  --    176    6    27    1  ---  CC: Data Entry MSB   

    97057  4  --    176    6    25    1  ---  CC: Data Entry MSB   

    97085  4  --    176    6    24    1  ---  CC: Data Entry MSB   

[TK.]

The output of the CRC application would be more interesting, a description what this application is doing can (always) be found in the main.asm file, but also at the right column of the MIOS download page:

This utility calculates the checksum over the MIOS program range. It can be used to ensure that the operating system has been uploaded correctly. The CRC will be print on the display and sent via MIDI (F0 <digit1> <digit2> <digit3> <digit4> F7). The current CRC can be found in italic letters behind the MIOS archive file

Which just means: compare the output with the CRC of the current MIOS release (it's BB15)

it seems that your monitor outputs the data in decimal format. It's better to switch to hex mode, the output should be:

F0 0B 0B 01 05 F7

(or in decimal: 240 11 11 01 05 247)

Best Regards, Thorsten.

[Jidis]

Thorsten,

I have gotten my PIC foundation stuff messed up a few times in the past, to where I wasn't getting the requests on boot or anything. I guess it could have been other factors (circuitry/burner?), but IIRC, I had done it each time by sending my Core some mangled version of an app compile. My memory on it's not that great, but it could also have been situations where a screwed-up, useless app I made would load, and then  the machine was inaccessible, but either way I couldn't get MIOS or a new app back in (even with an immediate boot xfer).

I've admittedly tried some weird source hacks, so I doubt he'd have a problem, but it does look like it might be possible. I've rarely done syx dumps (I'm usually doing hex xfers from MIOSStudio).

Sasa- FWIW, I think even having a simple, cheap PIC18 burner on hand is a good way to go, just to save you some emergency troubleshooting.

Take Care,

George

PS-->  I'm thinking I wasn't the only one who had ruined a bootload/MIOS setup before. I'll keep a close eye on it from now on, in case it looks like anything I could get a repro formula for.

[TK.]

Unrelated to your experiences, a change of MIOS is in my working queue, where I want to put the bootloader to 0x0000-0x03ff. This has some advantages (e.g. better PIC18F4620 compatibility, more space for MIOS apps) - one side effect will be, that this region can be hardware write protected. Unfortunately only on the PIC18F452... for PIC18F4620 it would be 0x0000-0x07ff, which is too much.

However, I'm still very sure that messing up the bootloader is very unlikely, which means: not impossible, but not a normal case.

Especially in Sasa's case, we know that he can upload code, therefore I still think, that recommenting to build a PIC burner won't help him - I just want to prevent that people think, that a non-working bootloader seems to be a usual case if something doesn't work, because it definitely isn't! And analysing the problems with the current flow - check if something can be downloaded, if not, work through the MIDI troubleshooting guide. Check CRC of MIOS, check to upload another application - will help to solve nearly 100% of all problems

Best Regards, Thorsten.

[TK.]

Just found out that Sasa's MIDI environment is a special case ;-)

Sasa: could it be that you've changed the ID header of your PIC - when I read your old postings, this isn't so unlikely that you forgot to mention such important details:

http://www.midibox.org/forum/index.php?topic=4190.msg27239#msg27239

Assumed, that you made some experiments with the change_id application, it could be, that you've changed the LCD type, so that the wrong driver is selected. The ID must be completely 0 for your MIDIbox

So, my proposals:

  - use MIOS studio, don't use any other tool.

  - please read http://www.ucapps.de/mios_bootstrap_newbiews.html

  - upload the official release of the change_id application to change back the ID to 0

  - if you are still using an older MIOS version: upload MIOS V1.8

  - thereafter upload the MIDIbox application

Best Regards, Thorsten.

[Jidis]

I just want to prevent that people think, that a non-working bootloader seems to be a usual case if something doesn't work, because it definitely isn't!

Didn't mean to give that impression. I have the power to break the "unbreakable". ;D

I mainly just don't feel like most people who are into  this sort of stuff, wouldn't have a lot of fun burning PIC's at some point anyway. Seems sort of sad not to have any burner at all. :'(

I want to put the bootloader to 0x0000-0x03ff. This has some advantages (e.g. better PIC18F4620 compatibility, more space for MIOS apps) - one side effect will be, that this region can be hardware write protected.

By side effect you mean a "good" one right?  Sounds good.:)  I've wondered before if there would be a way to put a "bulletproof" MIOS/MIDIBox dump into a PIC, like if you wanted to give someone else the box, and wanted to lock the contents, so they couldn't turn around and ruin it all. (like any of the old controllers with no learn or edit capability)

[Sasha]

Before I ask some stupid question I want to say, I read out everithing on the site so meny times but a lot of things is still not detailed enough to me to get it. I used to PC tutorials and lot of things here seams already known to people. Sorry but for me it should be more exactly like Click here, and you will see that here... I have no experience in any programming language so changing the codes is last option for me.

I am posting on this forum as a last option since I feel bad to bothering firstly TK with my problems but I just cant help myself anymore.

I read out main.asm of CRC application and also description on download page, and also search forum for some info but canot get where I should see the result of the CRC test besides on LCD.  I vas looking for BB15 in input monitor. Couldn`t find it. Maybe I couldn`t upload it correctly. I didnt reasemble the code since I didnt wanted to change anything. I just use main.syx code from crc.v1.5 directory. Is it OK to enough to see BB15 as the midi message in MIDI input monitor)?

more info what I`ve done till now:

- I programe bootstrap loader and 877 hexes with JDM this time.

- firstly bothe boxes was working

- I also have problems with recently working 16F877 box. Now when turning some pots in MIDI-OX shoving like sending notes, and some pots are sending sysexes. It looks very strange to me. I`ve put it aside for later debugging since my other 18F542 also have to be debugged for known reasons.

- I didnt mess up with changeing ID. only if it could happend accidentally. But I doubt it can be.

- I think I am using MIOS v1.7 (I`ll chane it to 1.8 )

[TK.]

Sasa, I must say that it's really difficult to help you, because you are mixing many things, and you are ignoring important tips which doesn't make it easier.

So, you want to have some step by step instructions, lets work it out:

1) Have you already installed MIOS Studio? Are you able to work with it, or do you need to know more details about the usage?

Best Regards, Thorsten.

[Sasha]

Have you already installed MIOS Studio? Are you able to work with it, or do you need to know more details about the usage?

Yes I have, and uploaded MIOS v1.8 yesterday trough MIOS Studio as you said. I have AIN and DIN hooked on the core and it is working OK. LCD... not.

[TK.]

So, here we've already found the problem: you haven't mentioned that you've uploaded the application after MIOS. This propably means, that MIOS hasn't been received by the core, because in this case the application would be disabled, and AIN/DIN wouldn't work until you are uploading e.g. midibox64

Let's doublecheck this: enable the "use feedback from core" option, upload the lcd7_clcd.zip application and copy&paste the messages of the hex upload window into this article. This gives me the information, if your computer MIDI Out -> core MIDI In connection is working.

In addition this application will bypass the ID setting, and print a message directly on the LCD (a good test application)

You should not receive AIN/DIN events anymore after the upload!

For the case that the upload stucks (since the core doesn't response), you can troubleshoot the MIDI In port based on these step-by-step instructions: http://www.ucapps.de/howto_debug_midi.html

Best Regards, Thorsten.

[Sasha]

Firstly, I must thank you and also apologise you for taking your presious time. LCD works now! As I said before, I checked conection LCD>CORE several times. My meter beeped every time I made circuit and I was 100% sure that wires are OK. Now I am confused. I use Floppy cable with original conector on the LCD side conected to the LCD over the SIL connector soldered to the LCD, and the other side also similar SIL connector. Whac could be the problem?

Sorry again for bothering you, I am sure I am going to need your help again since a lot of things are not clear enough to me. I apreciate your work very much, and I can`t thank you enough for your trying to help here on the forum.

Long time ago, just when I started making my first midibox plus, I said to myself I am going to make detailed and slightly better organised website when I finish everything so it could be helpfull for peoples like me. But I need to learn a lot of things myself as I go. I have teory about MIDIBox projects. You can do it properly only if you have all things in your head without checking this link or that page ;D

Thank you one more time TK, you made my life much happier tkan it was without your magic boxes.

I have one question, how can I take adventage of my 4x16 LCD. I fount that option somewhere but I am not sure can I use it without reasembling the codes. I am afraid of that a little... :-[

[TK.]

Well, this shows again, that somebody cannot check the LCD connections often enough...

To your offer for new documentation: we are going to improve the Wiki in order to put more newbie friendly information in there. The goal is, to have ucapps.de as "reference manual" site (maintained by myself), and the Wiki as "user manual" site (maintained by the users).

Improving the Wiki is very easy (once the new version is public, the old one doesn't work anymore), and if you are missing a certain tip and you know the solution, it will be very easy to add something without asking others :)

LCD mod: just have a look into the main.asm file, it contains all the settings. In your appr. case, search for "DEFAULT_LCD_SIZE", set it to 2 (4x16), build a new .hex (see http://www.ucapps.de/howto_tools_mpasm.html), upload it to the core.

You haven't answered yet, if the upload is working (because based on the previous posts, it doesn't). So, if you don't see any change after the upload, you need to troubleshoot your MIDI In port!

Best Regards, Thorsten.

[Sasha]

You haven't answered yet, if the upload is working (because based on the previous posts, it doesn't). So, if you don't see any change after the upload, you need to troubleshoot your MIDI In port!

Since I send sysx without problem, and it stays in I think It is working. Or you think I need to upload lcd7_clcd no matter it is working now.

I like Idea about Wiki but seams it is not live enough. I`ll do my best to improve it and share my experiences there.

[Sasha]

just have a look into the main.asm file, it contains all the settings. In your appr. case, search for "DEFAULT_LCD_SIZE", set it to 2 (4x16),

I really have problem identifiing "DEFAULT_LCD_SIZE" My logic says it is in mios_v1_8.zip or in skeleton_v1_8.zip. I found it in skeleton_v1_8.zip but couldn`t find "DEFAULT_LCD_SIZE" ???

[stryd_one]

That parameter does not exist in the skeleton application. The skeleton is an empty application for use when you want to write a new application of your own. In your case, you would want to upload another application such as the MIDIBox64, to make your midibox do a certain job. You will find the DEFAULT_LCD_SIZE parameter inside the main.asm file within that application.

Pardon me for saying so, but I think that maybe you need to read the ucapps.de website, this forum, and the Wiki, for a little longer, so as to get a clearer understanding of how it works. You will need to alter the source, compile the application, and upload it, after uploading MIOS. It is usually a simple procedure, if you take the time to follow the instructions. I know this project is really cool, and if you are like me, it is an exciting thought to rush forward, but a little patience will mean that you will be finished sooner :)