734 replies to this topic

[sliderpoint]

in the hardware installguide on mbed is stated that board FRDM-KL25Z is best mount in front on bottem , i have in my cabinet shaker in front , can i better not install it under my lockbar then , if i mount it on bottem in front will the nudge not be affected by the shaker ??

 

I have mine mounted under my lockdown bar and it works well there.

 

-Mike

[sliderpoint]

OK....I really need some assistance here.

 

I got my second controller. Followed the procedures, and when I plugged in the joystick port IT DID THE EXACT SAME THING. And now, the colored LED just stays white when you plug in either side and the pc does not recognize anything on the joystick side. It is exactly what the other one is doing. Everything shows correct in the SDA page.

 

So my question is what am I missing?? Here are the steps I took:

 

1. Plug in programmer side with reset button pushed - green led flashes, colored LED changes all sorts of colors

2. Copy over BOOTUPDATEAPP_Pemicro_v111.SDA

3. Unplug, plug into programmer port again and back in to bootloader - green led flashes, colored LED changes all sorts of colors

4. Copy over MSD-DEBUG-FRDM-KL25Z_Pemicro_v114.SDA

5. Unplug, and plug in again (w/o reset). This time it shows a 128MB flash drive called FRDM-KL2Z - green led flashes - colored LED changes all sorts of colors

6. Copy over Pinscape_Controller.KL25Z.bin - when this is copied green led flashes, but colored LED goes off

7. Unplug and plug into joystick port - nothing happens on PC, and green led flashes and colored LED goes solid white

8. If plugged into programming port again (and every time after) colored LED is solid white. (same with joystick port).

 

Very odd...I have to be doing something wrong. Is it possible my bin file is corrupt or for wrong thing? I recompiled it a few times, same results.... 

 

Is there a way to erase this and make it fresh?

 

ugh

 

 

When you hold reset button in and plug into the programming port does it still show up as a drive in Windows?  What is the name of the drive as it shows in computer?

 

-Mike

[Zablon]

Yes, it shows up as a BOOTLOADER drive. When I run the SDA info, it shows 1.11 and 1.14 (windows 7 by the way - 2 different pc's, different cables..scratching my head here).

Edited by Zablon, 30 January 2015 - 01:37 AM.

[javier1515]

 

I have a problem with the option of Ledwiz, install my KL25Z 5 Leds, DOF detects fine but the LEDs are always on.

installation that I have is simple, the leds 5v I draw from the power supply pc and each output to GND ports KL25Z.

What am I doing wrong?

 

Sorry if this is a stupid question. 

 

 

Cheers, Javier..

 

 

Nobody knows what the problem here.

[mjr]

OK....I really need some assistance here.

 

I got my second controller. Followed the procedures, and when I plugged in the joystick port IT DID THE EXACT SAME THING. And now, the colored LED just stays white when you plug in either side and the pc does not recognize anything on the joystick side. It is exactly what the other one is doing. Everything shows correct in the SDA page.

 

So my question is what am I missing?? Here are the steps I took:

 

1. Plug in programmer side with reset button pushed - green led flashes, colored LED changes all sorts of colors

2. Copy over BOOTUPDATEAPP_Pemicro_v111.SDA

3. Unplug, plug into programmer port again and back in to bootloader - green led flashes, colored LED changes all sorts of colors

4. Copy over MSD-DEBUG-FRDM-KL25Z_Pemicro_v114.SDA

5. Unplug, and plug in again (w/o reset). This time it shows a 128MB flash drive called FRDM-KL2Z - green led flashes - colored LED changes all sorts of colors

6. Copy over Pinscape_Controller.KL25Z.bin - when this is copied green led flashes, but colored LED goes off

7. Unplug and plug into joystick port - nothing happens on PC, and green led flashes and colored LED goes solid white

8. If plugged into programming port again (and every time after) colored LED is solid white. (same with joystick port).

 

Very odd...I have to be doing something wrong. Is it possible my bin file is corrupt or for wrong thing? I recompiled it a few times, same results.... 

 

That is strange - sounds like you're following the right procedure.  My guess based on the symptoms is that the Pinscape software is crashing or freezing during startup.  Here's my reasoning: the software never intentionally displays white on the LED.  White is what you get when all three color elements of the LED are set to full on.  During the initialization, the mbed library code sets all of the LED GPIO pins to ground, which turns the LED elements on (it's the same wiring logic as the LedWiz, also known as low-side switching).  As soon as the Pinscape software gets control from the library startup code, one of the first things it does is set all of the internal LED GPIO pins high, which turns off the LED.  So my guess is that the software is freezing up somewhere after the mbed library sets up the LED pins (grounding them, turning the LED white) and before the Pinscape code gets control.

 

Based on that, I'm thinking that the problem is probably initializing one of the other peripheral devices, such as the accelerometer.  Have you attached any wires to the new board yet?  If so you might try unsoldering everything and making sure none of the solder pads are shorted together, just to make certain you have a completely baseline hardware environment.  If you have any wires attached, it's possible that you've wired something in such a way that it's cross-wiring with the on-board hardware.  Many of the GPIO solder pads on the KL25Z board have multiple purposes that are shared with on-board peripherals, so it's possible to confuse things by connecting the wrong wires.

 

If you haven't connected any wires yet, I'm a bit stumped.  The next thing I'd probably try is running one of the really basic mbed sample programs to see if you can do the basic initialization and launch.  There's a simple example in one of the tutorials that just blinks the LED - I can hunt around for a pointer if you have any trouble finding it.  Give that a try and see if you have any luck with that.

[sliderpoint]

Yes, it shows up as a BOOTLOADER drive. When I run the SDA info, it shows 1.11 and 1.14 (windows 7 by the way - 2 different pc's, different cables..scratching my head here).

 

Here is a link to the .sda file that I used, maybe try copying this one.  Wait a while before unplugging and re-plugging.  Then try the pinscape software again (don't push reset button for that process, not that you did, just making sure).

 

-Mike

[Zablon]

On this one I haven't done any wires yet. I tried sliders SDA, no change. \\

 

I went out and tried a few demos (not sure which ones to actually do but I did try this one and a few others - I tried this one with no luck: http://developer.mbe...iveTouchButton/

 

This one doesn't work either: http://developer.mbe...-Blinky/compile

 

EDIT: finally did get one to work properly - http://developer.mbe...d_blend/compile

 

So my board isn't fried or anything. When I plug this demo in on the 'joystick side'. It does the same thing as the program side (the demo). So thats a good sign it is all working properly from a hardware perspective...

 

Not sure what the difference is in the 2 I posted above as they do similar things but one works the other doesn't.

 

It's almost like once I put the Pinscape Controller.bin on it, something just goes haywire. Is there a specific amount of time you need to wait when programming?

Are there different version so this model that might be causing issues? Seems odd if it was a hardware issue I'd have the same thing happen on 2 boards (btw my other board is fine as well). Like you said, maybe it has something to do with the accelerometer, but I couldn't find any demos that used it (with LED) that didn't require outside coding or something. I think I found one, and it did nothing.

Edited by Zablon, 30 January 2015 - 03:23 AM.

[sliderpoint]

Here is my Bin file if you want to try it.

 

-Mike

[mjr]

in the hardware installguide on mbed is stated that board FRDM-KL25Z is best mount in front on bottem , i have in my cabinet shaker in front , can i better not install it under my lockbar then , if i mount it on bottem in front will the nudge not be affected by the shaker ??

 

Mounting it under the lockbar should be okay, but I don't think it'll make much difference one way or the other with respect to the shaker.  Cabinets are pretty rigid, so I expect the vibration from the shaker will be transmitted to the top of the lockbar without much damping.  For what it's worth, my shaker is mounted a little forward of center on the left side, and the KL25Z is mounted a little forward of that toward the middle, and I don't see much obvious effect on the ball from the shaker.  The shaker is rather high frequency compared to nudging; I think it largely cancels itself out on the time scale that's important to ball motion.  But if you want to mount it near the lockbar anyway, I don't think that'll do any harm.  The important things are that it's roughly horizontal and fairly near the front of the machine.  Vertical position shouldn't make much difference.

[mjr]

On this one I haven't done any wires yet. I tried sliders SDA, no change. \\

 

I went out and tried a few demos (not sure which ones to actually do but I did try this one and a few others - I tried this one with no luck: http://developer.mbe...iveTouchButton/

 

This one doesn't work either: http://developer.mbe...-Blinky/compile

 

EDIT: finally did get one to work properly - http://developer.mbe...d_blend/compile

 

So my board isn't fried or anything. When I plug this demo in on the 'joystick side'. It does the same thing as the program side (the demo). So thats a good sign it is all working properly from a hardware perspective...

 

Not sure what the difference is in the 2 I posted above as they do similar things but one works the other doesn't.

 

It's almost like once I put the Pinscape Controller.bin on it, something just goes haywire. Is there a specific amount of time you need to wait when programming?

Are there different version so this model that might be causing issues? Seems odd if it was a hardware issue I'd have the same thing happen on 2 boards (btw my other board is fine as well). Like you said, maybe it has something to do with the accelerometer, but I couldn't find any demos that used it (with LED) that didn't require outside coding or something. I think I found one, and it did nothing.

 

I'm starting to suspect you do have a different model, given that the demos aren't working consistently.  Where did you buy it?  Do you have a link to the page with the manufacturer's part number?

 

In answer to your question about wait time, no: copying a .bin onto the boot loader disk automatically reboots the processor and starts the new program running immediately.

 

Are you running Windows 8 or 8.1?  If so, did you follow the special instructions involving doing the initial setup on a Win 7 (or earlier machine)?  I'm not even sure if that's still an issue, but when I first got my KL25Z, I had a heck of a time with weirdly unpredictable behavior - not quite like what you're seeing but similarly bizarre, where the simplest tutorials just would not do quite what the instructions said they should.  It turned out to be that the firmware they loaded at the factory wasn't compatible with Windows 8, and in fact was so incompatible that you couldn't even install the new firmware using Windows 8!  It would *seem* to work correctly when I tried, but then it wouldn't work properly for the demos and tutorials.  I would hope they've fixed this by now - it's been a year since I ran into this - but if you are running Win 8 you might try finding an XP or Vista or Win 7 machine and try starting over with the boot loader installation.

I have a problem with the option of Ledwiz, install my KL25Z 5 Leds, DOF detects fine but the LEDs are always on.

installation that I have is simple, the leds 5v I draw from the power supply pc and each output to GND ports KL25Z.

What am I doing wrong?

 

First, what kind of LEDs are we talking about?  

 

Second, how exactly do you have them wired?  Are you actually attaching the negative terminal of the LED to a KL25Z ground terminal?  If so that would explain why it's always on - the KL25Z ground terminal is just the same as the PC power supply ground, so you're just connecting the LED to power with no switching circuitry involved.  Always on is exactly what should happen if this is how you've wired it.

 

If you mean that you connected the negative side of the LED to a KL25Z GPIO terminal that corresponds to one of the Pinscape software's LedWiz emulator outputs, the problem might be that you shouldn't be connecting LEDs directly to these pins.  The KL25Z has *really* wimpy current sourcing/sinking limits.  You thought the LedWiz 500mA per port limit was hard to deal with?  Try *4* mA per port.  That's the KL25Z limit.  That's why I have all that extra circuitry in the manual for the LedWiz option.  You absolutely need some kind of amplifier circuit to drive *anything* with a KL25Z GPIO pin.  Those pins are only strong enough to drive a transistor base or FET gate.  If you just want to drive LEDs (either the small 20mA type or the 350mA type, as long as it's just one per output), you can just hook up the Darlington chip recommended in the doc (they're about $1 for an 8-output array) and wire each LED directly to a Darlington output.  I can sketch out the circuit for you if you're not sure how to do that.  Or better yet, build the full MOSFET circuit in the guide - that can handle just about anything you can throw at it, from LEDs to shaker motors.  I have mine running a 4A gear motor, a fan, a pair of beacons, strobes, a long string of undercab LEDs, and a couple of contactors.

 

Is there a way to erase this and make it fresh?

 

I'm pretty sure doing the full boot loader re-installation has this effect - the sequence where you unplug everything and then hold down the reset button while plugging it back in to the programming side.  That resets the boot loader, which is a separate master CPU that manages the storage device.

Edited by mjr, 02 February 2015 - 08:57 PM.

[Zablon]

 

I'm starting to suspect you do have a different model, given that the demos aren't working consistently.  Where did you buy it?  Do you have a link to the page with the manufacturer's part number?

 

In answer to your question about wait time, no: copying a .bin onto the boot loader disk automatically reboots the processor and starts the new program running immediately.

 

Are you running Windows 8 or 8.1?  If so, did you follow the special instructions involving doing the initial setup on a Win 7 (or earlier machine)?  I'm not even sure if that's still an issue, but when I first got my KL25Z, I had a heck of a time with weirdly unpredictable behavior - not quite like what you're seeing but similarly bizarre, where the simplest tutorials just would not do quite what the instructions said they should.  It turned out to be that the firmware they loaded at the factory wasn't compatible with Windows 8, and in fact was so incompatible that you couldn't even install the new firmware using Windows 8!  It would *seem* to work correctly when I tried, but then it wouldn't work properly for the demos and tutorials.  I would hope they've fixed this by now - it's been a year since I ran into this - but if you are running Win 8 you might try finding an XP or Vista or Win 7 machine and try starting over with the boot loader installation.

Is there a way to erase this and make it fresh?

 

I'm pretty sure doing the full boot loader re-installation has this effect - the sequence where you unplug everything and then hold down the reset button while plugging it back in to the programming side.  That resets the boot loader, which is a separate master CPU that manages the storage device.

 

 

I am running Win 7 64bit.. You said a few interesting things there. First, you mention that when you load the bin, it should reset and run. This is not what's happening for me. Even to get the couple I could get running, I had to unplug and plug back in before it would work. Also, even in bootloader mode, nothing reset my "white led" issue until I loaded another actual program or file (even dropping new firmware in didn't reset anything, etc).

 

I used the link in your doc:  http://www.mouser.co...FratDaJVW2nplde

 

Another question (and thanks for everyone's help and patience) - Do you happen to know what the program was that will load the default program it came with? It seemed to have a program  on it that changed the LED color depending on orientation of the accelerometer.

 

I tried your bin sliderpoint with same results as mine.

Edited by Zablon, 30 January 2015 - 03:05 PM.

[mjr]

I am running Win 7 64bit.. You said a few interesting things there. First, you mention that when you load the bin, it should reset and run. This is not what's happening for me. Even to get the couple I could get running, I had to unplug and plug back in before it would work. Also, even in bootloader mode, nothing reset my "white led" issue until I loaded another actual program or file (even dropping new firmware in didn't reset anything, etc).

 

I used the link in your doc:  http://www.mouser.co...FratDaJVW2nplde

 

Another question (and thanks for everyone's help and patience) - Do you happen to know what the program was that will load the default program it came with? It seemed to have a program  on it that changed the LED color depending on orientation of the accelerometer.

 

I tried your bin sliderpoint with same results as mine.

 

Okay, sounds like you must have the same device that I do, unless they've silently revved it or something.  It seems really unlikely that they'd do that and break compatibility so badly, though, so we can probably eliminate that.

 

The different boot loader behavior looks like the big red flag.  The behavior if you have the right boot loader should be that you copy the .bin file onto the virtual drive in Windows, the green LED flashes while the copying is going on, then the green LED turns solid and the device reboots automatically and starts running the new.bin file.

 

You are installing MSD-DEBUG-FRDM-KL25Z-Pemicro_v114.SDA as the last boot loader install step, right?   It sounds like you might be installing the other boot loader (DEBUG-APP_Pemicro_v102.SDA) since you're not getting the auto-restart behavior.

 

Are you doing the step where you hold the reset button while plugging in *after* installing the boot loader?  Doing that reboots the boot loader, so you'd have to start over with the boot loader install if you *ever* do the hold-and-plug-in step again.

[Zablon]

Can you clarify? I posted my steps verbose a few steps back - my understanding is the you press reboot for the bootloader, then press reboot for the 114SDA, then not after that for the .bin file. And yes I'm using the v114.SDA.

 

Maybe this is just the worlds way of telling me I don't need analog plunger. My virtual plunger from Noah didn't work either :/

[sliderpoint]

I believe the steps are :
Unplug
Hold reset and plug into dev port
Drop sda file.
Unplug
Replug into dev port
Drop bin file
Unplug
Replug into gameport side

-Mike

[mjr]

Can you clarify? I posted my steps verbose a few steps back - my understanding is the you press reboot for the bootloader, then press reboot for the 114SDA, then not after that for the .bin file. And yes I'm using the v114.SDA.

 

Maybe this is just the worlds way of telling me I don't need analog plunger. My virtual plunger from Noah didn't work either :/

 

Okay, I found your older post, and I can't see anything wrong in the boot loader update procedure.  I'm pretty stumped.  Are you at all comfortable with C++?  If I were having this happen I'd try building some really minimal test programs on mbed - say, just turn on the red LED for starters, then maybe make it flash red/green or something like that - as a sanity check that the basic mbed startup code is working.  Given your mixed results with the demos, I'd want to see if the simplest possible programs like this would start up properly.  Again, a new program should start running IMMEDIATELY when you download the .bin file, no manual rebooting or unplugging required, which makes blinking LED programs easy tests to run - you can see right after dropping the .bin file if it started up properly just by looking at the LED.  

 

Even if you're not comfortable writing your own C++, you can follow these examples without having to do much beyond operate the mbed compiler environment:

 

http://developer.mbe...-KL25Z-Examples

[boiydiego]

 

i use a real tiltbob. you just need to ad some lines to val.keydown script to have no bangback in vp... It works perfect...
Sub table1_KeyDown(ByVal Keycode) If Keycode = MechanicalTilt Then vpmTimer.PulseSw vpmNudge.TiltSwitch

 

I think you've got the right idea.  Looks like all of the code that handles this is in scripting, not in VP itself.  Rather than modifying every table's keydown script individually, though, it looks like it might work to modify core.vbs to change cvpmNudge.DoNudge to read

    Public Sub DoNudge(ByVal aDir, ByVal aForce)
        if TiltSwitch <> 0 then vpmTimer.PulseSw TiltSwitch
    End Sub

That eliminates keyboard nudging centrally, so that you don't have to make any changes to individual table scripts, and instead simply pulses the ROM tilt bob switch on any software nudge event.  Presumably the only software nudge events in a cabinet would be from the physical tilt bob, in which case this will do exactly what you want by connecting the physical tilt bob directly to the ROM tilt bob switch.  If for some reason you still want to be able to do manual keyboard nudging, this approach won't work, but I don't see any reason to use keyboard nudging if you have an accelerometer and a tilt bob.

 

 

i always had tilt bangback in vp with my tiltbob ,it always tilts multiple times when only hitting the ring of the bob one time , do you have a modified core.vbs mjr ?

Edited by boiydiego, 10 February 2015 - 12:14 AM.

[mjr]

 

 

i use a real tiltbob. you just need to ad some lines to val.keydown script to have no bangback in vp... It works perfect...
Sub table1_KeyDown(ByVal Keycode) If Keycode = MechanicalTilt Then vpmTimer.PulseSw vpmNudge.TiltSwitch

 

I think you've got the right idea.  Looks like all of the code that handles this is in scripting, not in VP itself.  Rather than modifying every table's keydown script individually, though, it looks like it might work to modify core.vbs to change cvpmNudge.DoNudge to read

    Public Sub DoNudge(ByVal aDir, ByVal aForce)
        if TiltSwitch <> 0 then vpmTimer.PulseSw TiltSwitch
    End Sub

That eliminates keyboard nudging centrally, so that you don't have to make any changes to individual table scripts, and instead simply pulses the ROM tilt bob switch on any software nudge event.  Presumably the only software nudge events in a cabinet would be from the physical tilt bob, in which case this will do exactly what you want by connecting the physical tilt bob directly to the ROM tilt bob switch.  If for some reason you still want to be able to do manual keyboard nudging, this approach won't work, but I don't see any reason to use keyboard nudging if you have an accelerometer and a tilt bob.

 

 

i always had tilt bangback in vp with my tiltbob ,it always tilts multiple times when only hitting the ring of the bob one time , do you have a modified core.vbs mjr ?

 

 

No, that was just an idea to look into.  I haven't had a chance to work on that in a long time - it's on my to-do list to investigate this and find a definitive solution to plumb bob tilting, but I have some hardware tasks that are ahead in priority right now.  But if I recall correctly, mapping the physical plumb bob to VPM bang-back will do exactly what you're experiencing (with generic core.vbs) because of the way VPM routes this.  My recollection is that the key sends the physics engine a powerful virtual jolt, which sets VP's *virtual* plumb bob reeling, which ends up triggering several virtual tilts, which pulses the ROM tilt switch several times in a row and causes the ROM to register a tilt.  My thinking is that the virtual bob has no reason to exist in a cabinet with a real tilt bob, so I want to bypass all that and just have the physical tilt bob send tilt switch pulses directly to the ROM, bypassing the VP physics engine entirely.  The core.vbs change above *might* get us part or all of the way there, but I haven't studied this to enough depth yet.

[boiydiego]

i hope you can get this working lots of use have tiltbobs so normaly everybody that has one will have the same problem and its realy not fun to nudge the cabinet and just tilt it one time and fully tilt the table so gameover bye bye highscore

 

also mjr can you look at the threat where i have a problem with the flipperbuttons , just posted it not here mistake..

Edited by boiydiego, 10 February 2015 - 10:51 AM.

[mjr]

also mjr can you look at the threat where i have a problem with the flipperbuttons , just posted it not here mistake..

 

Must have missed that - if you can give me a pointer to the post, I'll take a look.

[boiydiego]

http://www.vpforums....513#entry297158  thx mjr

 

the deadzone is now on 42 that is alot i think doenst it spoil the nudge effect greatly ?

Edited by boiydiego, 10 February 2015 - 06:02 PM.